Higher order component for CRUDs?

[HaGuesto]

Boxwise basically consists of CRUDs-"components" (Boxes, products, categories, user management and some more). All of them are very similar. We are thinking of creating a Higher order component (HOC) to standardize these CRUDS. This way we limit the redundancy in our code which will make it is easier to debug / test / maintain. In theory in the long run we are faster developing. If we're able to make this abstraction with a concise API and a good documentation, it will be very easy for newcomers to create new CRUDs in no time. Another advantage is going to be the implementation of permissions/roles.

The question is: Is it worth to invest time in it at this early stage?

What is a HOC?

HOC (Hight Order Component) is a function that receives a Component and return another Component with your desired changes (It is basically a decorator).
The most common example is connect from react-redux (its a composed function though, but works like a HOC in the end).
Another example one we use in our project is the withStyles HOC.

Anything to add @rubenspgcavalcante ?

[rubenspgcavalcante]

I think the answer to the question

The question is: Is it worth to invest time in it at this early stage?

is already there haha! Makes no sense to try to build a abstraction like this after have tons of CRUDs already implemented ( in their own way) inside the project. My opinion based on previous experiences, If we don't do it now, we don't do it at all

[bfirsh]

I have no strong opinions.

There is a risk with these sorts of abstractions that they make things more complex for people to understand what is going on and harder to implement new things, particularly if you want to make slight modifications. E.g. say you want to make a normal crud, but with a slightly different list, or whatever. Verbosity might be preferable for that reason, even if you are repeating yourself. (Compare Rails' implicitness/magic with Django's explicitness/verbosity.)

I'm not for or against something like this, but worth keeping in mind.

[rubenspgcavalcante]

For sure, open for extension closed for modification.
Also, as the HOC will only bind the generic actions and app state to the component we can break this in three parts:

• A set of generic actions (and reducers) related to CRUD which modifies in a uniform way the app state;
• A HOC which binds the actions to whoever component we want;
• A set of generic Components which can be easily extended and have all the properties (API) to being connected to this HOC;

This way we can separate the generic CRUD API for data, view and the bridge to do that :)
We can have this example of cases in mind:

Custom Component

We have a CRUD which don't uses the CRUD table EntityListTable to list the entity collection, but a infinite scroll. Using a Duck Typing strategy, we'll be able to create a InfiniteScroll component just exposing the right properties to connect to the CRUD HOC (and adding more actions/states if necessary).

Custom Action

On the listing, we want to add a additional filter step. As the CRUD generic action is just a thunk we can extend it creating another thunk with this additional filtering step and pass it to the HOC

Custom State

We have a CRUD that receives a routing parameter which modifies the forms behaviour/UI. As we can pass custom actions to the HOC mapping, we should be able to pass custom states to the HOC too.

[rubenspgcavalcante]

@bfirsh Some abstractions, if made in the right way, isn't only good for DRY but can, for sure, turn things simpler (even to test!). Take the frameworks and libraries we use as example. I think if we maintain in mind the KISS and the open/closed principles we can achieve something nice :)

I can tell for you that CRUDs tends to grow on the system, (and each one in a different way). It's a hell to maintain, and when you find and fix a bug, you need to go checking all the duplicated code (most of times manually, as the name of the methods and vars aren't the same), and go fixing one by one, not being sure if is working or not (of course if you don't have tests).
With this in mind I'm totally in of doing most of the stuff in a uniform way and all the specific stuff, doing it specific 👍

[HaGuesto]

@DurkoMatko This is what we talked about today

@jamescrowley do you have an opinion? Should we add this abstraction layer now before we create CRUDs for category and attributes in #506 and #507