Rekit without Redux?

[brody4hire]

I found the nice "feature oriented architecture" article last year, wondering if there may be any way to do this without depending on Redux?

Motivation is that there is an increasing number of alternatives to using Redux, for example:

• https://medium.freecodecamp.org/replacing-redux-with-the-new-react-context-api-8f5d01a00e8c
• https://hackernoon.com/redesigning-redux-b2baee8b8a38
• https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367
• https://medium.com/hyperapp/hyperapp-for-redux-refugees-2507c9dd1ddc

I would be happy to take a look at this one when I get a chance, someday.

[supnate]

Hi @brodybits , thanks for the question. Redux is currently the best choice for state management of large scale application in my opinion. Rekit's design is just based on Redux heavily so it's not easy to remove it and mean while keeps the scalability of the created app. However you can of course choose to not use it but just leave the configurations there. That's fine.

To support other approaches of state management, you can create a Rekit plugin for managing boilerplates.

[leob]

I'm backing @supnate on this, React is already confusing enough, with way too many alternative ways to do something.

The strength of a framework like Vue.js is that it provides most of what you need out of the box as a standard solution, so people waste less time on making choices. The philosophy of Rekit (correct me if I'm wrong) is to bring this kind of simplicity to React, giving developers an opinionated, 'standard' way of doing things, with fewer options and fewer choices to make.

Given this I'd say that the choice for Redux is a logical one. Redux provides a simple and easy to understand model for state management (you do write some boilerplate but there are ways to mitigate that). I think if you start adding alternative options like the Context API (which wasn't even officially endorsed before React 16) or Mobx then you throw the baby out with the bathwater, because the essence of Rekit is simplicity and giving developers one 'standard' way of doing things.

But if there would be a simple and 'clean' way to integrate Mobx (via a plugin or something) then that might be something worth considering I suppose ... don't know how big conceptually the difference is between Mobx and React (I've heard it's similar to Vuex in the Vue.js world).

(by the way, I saw that Rekit does support the choice of using either redux-thunk or redux-saga, this is a good thing because both are popular choices within the Redux world)

[supnate]

Thanks @leob for the comment! Your feeling about React does make sense, I think too many choices really confuse many new comers. But a community with continuous innovation and evolvement is really exciting. It also brings a lot of fun when you see new ideas come up every day or every week. I believe this helps to push frontend development to go forward in a brilliant way. Everything has two side effects.

For Rekit most of your thought is right. Actually the most opinionated part of Rekit is the folder structure, that is how to organize your source code in a scalable way, but not the tech stack choice. Rekit is originally created to help generate/refactor/analyze your code so that you could focus on business logic other than too much boilerplate code. To achieve it, Rekit need to understand your code. That is, Rekit need to understand the technology you use, when it knows redux-thunk, it helps to generate code for you; when it knows redux-saga, it helps to generate saga code for you.

So actually Rekit doesn't limit which technology to use, we can create plugins to make Rekit support(understand) more technologies. To give a good start, it choose Redux, React router since they are popular widely verified that they work well for large scale projects.

And maybe someday Rekit could also support to create Vue project. That's really in my mind!

[leob]

Vue with Vuex would certainly also lend itself to this architecture, good idea for the future.