Introducing Redux (or similar state management)

[matthewoestreich]

Hey @Domino987 what are your thoughts on introducing Redux?

[Domino987]

Hi @oze4 , I already thought about this a lot actually. But there are a lot of things to consider and how we manage it.
Redux is too bloated IMO. I would use either Zustand or recoil for it.

But a better approach may be using formik with context maybe. This would be awesome because we don't need to write update error and touched logic.

But this comes with one big if, we would need to make sure that data and columns are memorized to update. This would allow us to track when the data changes and to track this reasonably, useMemo or similar stuff is needed. Just like react -table does it. But this would be a big breaking change

[matthewoestreich]

Yea I would rather use something other than Redux tbh. The only reason why I think it would be a good idea to use Redux is due to the ecosystem/community. If we use state mgmt library that nobody knows, it is highly unlikely they will contribute imo. It essentially makes small fixes, big ones (# of issues goes up - # of PRs goes down).

Over the past day or two I rewrote the Toolbar component with Redux (on a separate branch) just to see what it would look like. I don't think those props would need to live in global state, I wrote that moreso to see what the structure would look like. It was just easy to do that with the Toolbar.

Here are my thougts..

Good

• I really like the implementation/structure as it feels very organized to me
• Especially the hooks
• I mirrored a repo I found online - I'm not taking credit for this pattern
• A ton of people know Redux
• I've used Redux prior to Hooks, and Hooks make it a ton easier

Bad

• It's bloated
• I think it may be overkill
• I already encountered issues (I believe passing the raw React element to Redux causes it to freeze at first, due to how large the actual object is)
  • The issues are with setColumnsButtonAnchorEl and setExportButtonAnchorEl if you're curious....

I plan on creating another branch using native context API, to see what that feels like.. Using context with useReducer feels very much like Redux with Hooks, which I did enjoy.

I'm open to anything, so if you want to create some POC's as well that would be awesome!

I don't know Formik but I've heard nothing but good things about it and would be happy to learn it.

[matthewoestreich]

Also, the Redux lag could be due to react-beautiful-dnd.

I've had an issue open for a very long time with 0 movement. It causes pretty bad slowness issues over time and still effects this library. So that may be why it freezes as well?

I think we may also need to get rid of react-beautiful-dnd during the addition of state mgmt. It's extremely bloated for such "ok" functionality.

Using some sort of global state will also allow us to rewrite much more efficiently as we can truly separate props from state (aka props drilling).

I can't find anything on whether or not Material Design allows for draggable columns or not, so I assume it's not something we should include? Then again, there are a lot of those Material Design "rules" that this library breaks so I'm not sure how closely you want to follow those guidelines. I'm ok with bending the rules if you are.

[Domino987]

What kind of rules do you mean in particular?

[matthewoestreich]

The rules that define what material design is. Google developed standards to follow for material design. Everything from margin sizes to data tables.

https://material.io/components/data-tables

[matthewoestreich]

@Domino987 I've been checking out Zustand today and I'm a big fan! I really like it.

[Domino987]

I like zustand as well. Did you take a look at formik? It opens a local context for display and updating. This would also remove the need of updating values in itself, so the edit functions would be a lot easier as well.

Ia grre with you tha we nned to remove the prop drilling and the 100238427 props passed to body. In addition to some management, composition would improve the code as well:

<MTable {..ALLTHE_PROPS} />

but instead

<MContainer {..CONTAINER_PROPS} >
     <MToolbar {..TOOLBAR_PROPS}/>
     <MHeaderRow {..HEADER_PROPS}/>
     <Body {..Toolbar_PROPS}/>
     <Footer {..FOOTER_PROPS}/>
</MContainer>

Formik with React.memo should work like a charm.

Regarding the dnd. ITs super clunky and bloatd. I am thinkout about removing it in favor for somehting smaller/simpler. Maybe https://github.com/react-dnd/react-dnd/

[matthewoestreich]

I did look at Formik but not for very long tbh. So I can't really give a fair opinion. In the short term, Zustand got my attention so I focused on that. I think ide rather use native context myself vs Formik. Native context API is extremely easy to use and I've got experience with it.

I need to look more into Formik though. Otherwise my opinion will be somewhat bias. Right now I love Zustand, but again idk mich about Formik (but will make learning it a top priority this week).

[matthewoestreich]

Also I'm a big fan of something other than react beautiful DND. Idc what we replace it with as long as we replace it lol

[matthewoestreich]

I think I would rather use our own implementation of native context api vs Formik.. Mostly because Formik seem tailored towards forms.

Meaning, we would only be taking advantage of the "wrapper" they use around context, which is very easy to do yourself. So I don't see the benefit I guess.

You can accomplish the same thing with Redux/Zustand as well (as far as each component has it's own state, which is what I think your example code shows).

Did you check out the hooks example? It appears you can do that with Zustand, too.

Here is an example hook.

Here is that hook in use, which replaces this code essentially.

[matthewoestreich]

@Domino987 overall my thoughts are this...It doesn't really matter to me what we use - I just want to use something lol. Global state will make so many things so much easier.

Specifically, separating props from state (this concept is HUGE).

Here's my preferences:

1. Zustand
2. Context API (with useReducer and hooks)
3. Redux
4. Formik

With that being said, if you want to use Formik then let's start using it.

Thoughts?

[Domino987]

I agree. I am not invested in formik so let's try Zustand and see how it goes.

[flora8984461]

I've been using formik for some time, I think their idea of context is just the same as Context API? Formik is a library to build a form app, and it wraps its functions & form values into context so that I can use it from anywhere within <Formik />

https://github.com/formium/formik/blob/master/packages/formik/src/FormikContext.tsx

[matthewoestreich]

Thank you! I think the final tool we decided on is Context. Not any third party library.

[Domino987]

Looking at this from bundle phone, i think we should try to reduce the package size if possible.

[matthewoestreich]

Agreed. Getting rid of react-beautiful-dnd would also get rid of react-redux (since react-beautiful-dnd uses react-redux). Sadly, react-dnd also uses redux so it seems we will be using redux regardless. Which makes me think should we just use redux instead of adding another dependency (in this case zustand) and therefore making the bundle larger?

As far as date pickers - we could handle that in the same way we handled exporting (by using a separate package @material-table/pickers or something).

So, the question is: should we replace react-beautiful-dnd first or do we introduce Zustand first?

I honestly think replacing react-beautiful-dnd is a smaller/easier task so maybe we should start there?

[Domino987]

Or we get rid of beautiful DND and react in one move, use a smaller DND lib and use Zustand for our use case?

Using a custom date pickers is a great idea.

So we get rid of beautiful DND and see where this leads us 👍

[matthewoestreich]

Completely agree. Just wanted to point out that react-dnd (not beautiful) also uses redux.

So instead of adding Zustand, should we just use redux since it will be included with our bundle anyway?

[Domino987]

Yes, if we use a long that already uses redux for sure. What about https://bundlephobia.com/[email protected]. i would like to avoid binding redux in the first place since it's 5% of our current bundle for sich a mundane functionally.

[matthewoestreich]

Agreed. I'm down to use that (or anything else without redux).

[Domino987]

Can we create a new branch and start working on it?

[matthewoestreich]

For sure

[matthewoestreich]

@Domino987 just wanted to make sure you saw this.

[Domino987]

I started a sandbox on how we could remove beatifull dnd: https://codesandbox.io/s/react-dragtastic-example-forked-ksicx?file=/index.js

WE just need the sorting and we should be able to get it going.

[matthewoestreich]

Nice! I like it. Good work.

As far as Zustand goes - I created a fork, but since I have no experience with it I'm not quite sure how to structure things. Although, I know Zustand supports "middleware", which I think may help with structuring things.

See here for Toolbar store, and here for Toolbar store in use.

• It is also important to note as far as passing a React.element into state, I encountered the same issue with Zustand that I did with Redux It looks like a different issue unrelated to state management
  • (if you clone that fork and run npm start, then go to the ColumnsButton demo you'll see what I mean after clicking on the Columns Button)
• The code feels like it can quickly get out of hand imho
• At that point the code is still a mess, which global state is supposed to help with
• To me, it feels no different than having a "data-manager.js" for each component, if that makes sense
• That's one thing I do like about Redux; it almost forces you to be organised.

After using Zustand I would almost rather use context API or Redux instead.

It is likely things could be structured better but I wasn't able to find many example projects online and the docs aren't that great for Zustand.

I say we create a fork using context API just to explore all avenues. Thoughts?

[Domino987]

Hi yes I saw it but I wanted to take my time to evaluate everything.

So first of , the anchors would not be moved into the state, since they can just be local state, since nothing outside of it cares about it IMO.

But about the library. I agree it may be a little bit to fiddley/micromanagement to our use case to use zusatnd.

How about since we already have redux in it, we use the redux toolkit and try to move everything that is needed outside of a component/shared between them into redux. This should drasticly increase performance and the prop drilling.

Also I was thinking about making the columns and data immutable so that we can easily track if the data and columns changed just how react-table does it: https://react-table.tanstack.com/docs/quick-start#getting-your-data

So lets dive into redux?

[Domino987]

This could probbly triggered with a middleware or useEffect hook so that we dont have to pass the callbacks down to the compoents but access them at top level.

[matthewoestreich]

If you feel comfortable building the structure for Zustand then I can follow your lead. I am just not as familiar with Zustand as Redux.

Also, the toolbar example was just to see how things may look. I agree that in "prod", those anchors should stay in local state. It was more for an example, it was just easiest to do that with the Toolbar.

I 100% agree - it would help us on so many levels.

[matthewoestreich]

Also I love that immutable idea. I think that would be huge too!

[Domino987]

@oze4 something like this?

[matthewoestreich]

I was so confused at first then realized it's redux toolkit lol. Idk redux toolkit so I'd have to dig deeper into that first.

At face value tho I do like the structure and what youv'e done.

[peacechen]

Moving my comments from the other thread.

I generally like redux and have used it in my projects, but not all projects need it. Redux is 170 kB, react-redux is an additional 278 kB, for a total of 448 kB. That's a hefty chunk that all apps are forced to use regardless of whether they want to or not. I understand that react-beautiful-dnd uses redux so it's already pulled in. Long-term, consider searching for a viable substitute that doesn't use redux. With that in mind, I recommend not locking this project into redux unless there's a compelling need for it that React context can't provide.

At the library level, we should use the simplest solution that meets our needs. Refactoring this project to redux would take effort; it would take even more work later to refactor out of it. The decision to use redux should be at the app-level, not the library level IMHO. This library isn't as complicated as a full application so it's hard to justify the added complexity and weight of redux. By adding redux as a core dependency, this library becomes blocked by bugs in redux.

[peacechen]

Hookstate is another state management tool that came across my feed. Not advocating for it, just adding it to the list in case it offers something we need. Unpacked size looks comparable to Redux (not sure how much smaller it is tree-shaken and gzipped).
https://hookstate.js.org/
https://blog.logrocket.com/simplify-react-state-management-with-hookstate/

[matthewoestreich]

@peacechen @Domino987 I went ahead and started to integrate context...

The context branch..

The main areas of concern: store, and using the provider.

Thoughts?

Keep in mind it is just the start.. I wanted to see what you thought about the structure, etc.. or get any input you may have.