Is there any way to access all of ReflexElements' sizes at once?

Currently, the only way to get flex values are to listen to the onResizeStop but that only gives access to the data of the two ReflexElement being resized. I checked the docs, the relevant piece seems to be: https://gist.github.com/leefsmp/28ceb226d119d179d1e94466d2dd1a8b#file-re-flex-demo-storage-jsx

However, this misses a few cases:

1. What do we do if we have more than 2 items? The resize event will only fire for two items but ignore the third (as it should). We’re left to guess the flex of the 3rd, 4th,… item.

2. Tied to 1 but data can only be retrieved when a resize happens. While you can provide initial flexes, let’s assume from local storage, you’d need to have performed an onResizeStop event on all the ReflexElement components for you to be able to store ALL the values.

This can be mitigated by providing initial flexes on all the elements and then updating these that need updating on the onResizeStop event, but was wondering if this information was exposed somewhere.

[leefsmp]

Yes I agree with you, the approach of the initial implementation of the lib is getting rusty. I was thinking about a complete rewrite of the internal logic based on context and hooks. I will try to find a moment to look into it. In the meantime if you have design recommendations for that next version, I’m happy to hear it maybe in a new issue thread so it’s easier to follow. Thanks for the constructive feedback.

[growthwp]

I am not aware of the issues you faced, the contexts in which the library is used, so, I can’t say anything. However, here’s an implementation of an accordion component in which all the data-flow is completely separated from the UI:

https://codesandbox.io/s/strange-leakey-1z1lz?file=/src/App.js:348-369

This doesn’t use context in the way I recommended, but you can see how I have access to all the internal data of the accordion:

• Which panels are open.
• Based on the above, what is my inner output (what do I get to display)
• Panel keys, panel names,
• Their state: open/closed.

So what does this all achieve? Well the useAccordion hook is a barebones data manager while withAccordion deals with figuring out data one level higher: the click handlers, the content, etc. Obviously, this is not perfect design and perhaps the two things could be merged but you get the point - I get a concise place for all phases of how it works. All of this allows me to write any markup I want for my accordion. The hooks don’t spit out any markup at all, as you can see, it’s all handled in App.js’s .map.

Composition can easily be achieved by using refs or injecting the variables that come back as props for elements, just as dnd-kit does it:

https://docs.dndkit.com/api-documentation/draggable#node-ref

Since a library needs to be batteries-included, I’d also include the presentational layer of what is App.js in my case, since people just want to import something and it to work.

Hope this at least gives you some starting points.