Access to batch state outside of listeners?

[membla]

Hello and first off thank you for this great library! I might have missed something here but your answers in e.g. #543 makes me think this is by design.

In our solution we have multiple upload components of different types that all are managed by a single Uploady context. This lets us mount and unmount the actual upload components without having to worry about interrupting the upload process. All good.

However, if the only way to get access to the batch state is through listeners, how can we initialise the component state when an upload component is (re)mounted and there are batches in progress? We clearly can handle this separately but it certainly feels like this use case shouldn't make these very handy listeners/hooks unusable for this.

[yoavniran]

Hi @membla
This is indeed by design.
What I do in most projects that require this kind of state persistence is to create an UploadyConnector component that renders Uploady and also registers to the relevant events. It can then store the info in its own state (useState) or external store (redux, mobx, zustand, etc.). When components are rendered (re-mounted) underneath it, that state can be provided as props or by pulling from the store.

Since in most cases the raw Uploady state isn't enough and applications augment/change it to their own needs anyway, I think the current design of the life-cycle events is the most flexible solution.

Thanks!

[membla]

Thank you for your answer @yoavniran. Got you – although I fail to see why the batch state couldn't/shouldn't be accessible at will but only through the listeners I haven't digged in the code base here. It does feel strange to be forced to replicate state that is already present though, just my 2 cents. Thanks again.