sizes property doesn't is not a dependency

[photoskiff]

Hi John,
It doesn't seem to be possible to update sizes programmatically (reset for instance) since the useEffect doesn't have a dependency on sizes property.
Very nice component btw, I like how it manages a group of panes

[johnwalley]

Hi @photoskiff. Thanks for the feedback. I put in the sizes and onChange props to support saving the pane sizes and setting the initial pane sizes when you mount the component at a future point in time. Which is a long way of saying that it's deliberate that the component doesn't expose a way to programatically update the pane sizes after mount.

I think that's a sensible decision but there are some actions which it does make sense to expose programatically. Particularly, the one you mention, resetting the layout (the same as double clicking). I could add a method to the component's ref which you could call to reset the layout, e.g. ref.current.reset(). Would that be helpful? Are there any other actions you can think of?

I will also add some documentation making it clear what the behaviour of the size props is.

[johnwalley]

Hmmmm, the more I think about it, the more I can see a use case for setting the sizes of the pane s programmatically. It would have to be done by a method on the component reference because it's an imperative type of operation rather than a declarative prop. I'll mull this over.

[johnwalley]

I've created PR #69. It needs testing before merging and publishing. If you get a chance to take a look that would be great. Regardless, I should get around to it tomorrow.

[johnwalley]

The example is deployed to https://deploy-preview-69--allotment-storybook.netlify.app/?path=/story/basic--reset

[photoskiff]

great, thanks!

[photoskiff]

I can see a reset method added to ref. is there a reason you don't want to simply change useEffect this way useEffect(() => {...},[sizes]) ? then it would probably work straight away and wouldn't require tight coupling between button and allotment. The biggest hurdle I see is that if I have several allotment components I don't want to connect to all of them. I just want to pass a state to my parent and allotment components would consume their part of state (redux, recoil scenario) the reset button might be anywhere in the application

[photoskiff]

here is an example my state would look something like this: layouts: number[][]
<Allotment vertical sizes={layouts[0]}> <Allotment sizes={layouts[1]}> <Component1 /> <Component2/> </Allotment> <Allotment sizes={layouts[2]}> <Component3/> <Component4/> </Allotment> </Allotment>

[johnwalley]

Sure, let me try and explain where I'm coming from 🙂.

React components are intended to be declarative. In the sense that the props you pass in will be reflected in the output (usually html). A common exception are default or initial props. Which is how sizes works in Allotment. A good example would be an uncontrolled component behaving like an input element. You would pass a defaultValue prop but after its mounted it manages its own state. For performance sensitive components (like Allotment) which might generate a lot of updates it's often beneficial to make them uncontrolled and let them manage state outside of the React lifecycle if necessary (which is what Allotment does).

What I think you're describing is neither a declarative controlled component (i.e. pass in sizes and that's what you see, onChange could be used to close the loop) nor an uncontrolled component (i.e. pass in initial sizes but from then on the component is in charge).

I usually advise developers not to implement components which treat their state as a side-effect. You often see this when a component performs a particular action (like resetting) when a prop changes value. This sort of 'change detection' is sometimes a poor man's attempt at implementing something which would be better off as an action (or event). In the case of Allotment we could add a setSizes() method. I hear what you're saying about having to manage the refs but you could accomplish what you're after by putting a wrapper around the Allotment component which detects when sizes has changed and calls setSize. I feel that type of behaviour is better off in the calling code rather than the library.

Another way to think about this is what should happen in the following case:

1. pass sizes to get initial layout
2. user changes the layout
3. as a developer you want to set the sizes back to what they were in step 1

But you can't simply pass in the same array as it wouldn't trigger the change. You could pass in a new array with the same elements but at that point you're really fighting against React.

Btw I appreciate all your input and I'm not saying I'm necessarily correct in what I say. I'm basing it on my own experience.

[photoskiff]

sizes is just another property of the component like color, width, length etc. I don't see any difference. You change a property and a component will react accordingly. I don't see anything here that goes against react nature or good practices here because we don't implement this feature only to do resetting.
Resetting is just a special case, you can think of many other scenarios when you might want to dynamically set panes to certain ratios.
Btw, it's a nature of state management that the state is immutable so you always would pass a copy of the array that would trigger the change. And it's up to developer to make sure they pass a different property object to a component to ensure it's update, that is a normal practice.
And any wrapper would really be very cumbersome to implement for a complex layout of allotments.
the whole idea of state management frameworks (redux, recoil etc) is about reducing dependencies and tight coupling between components by centralising some common shared state. I should be able to send a message from one component and via a mediator and get it reacted.

[photoskiff]

making a simplest possible change useEffect(() => {},[sizes]} instead of useEffet(()=>{},[]) will increase usability of the component dramatically and frankly it's beyond me why adding the ref complexity (tight coupling) and still restricting functionality can make it better. In fact it's a matter of people using it or going for another library, in my case - definitely so.