Loomio
Mon 23 Apr 2018 12:51PM

Separation of state and components

AA Andrea Ascari Public Seen by 205

In the current state of art, the components handle big part of the app's logic, as well as state and api calls.
To have a more maintainable code and to reduce the overhead for new developers to get familiar with code I would separate the logic from the components, with the aim to have as many stateless components as possible.

I have a couple of suggestions to address this problem (and no, it's not Redux), but I would like to hear from you at first.

D

Deam Mon 23 Apr 2018 1:03PM

I agree. The Ideal thing would be having a library only with UI components which can be mixed and matched. Something like https://github.com/aragon/aragon-ui.

S

Satya Mon 23 Apr 2018 7:54PM

Yes you are right, and this is something we want to do. Our plan was to do this together with the implementation of the context api but if you have other suggestions please present them in the dapp meeting for discussion.

V

Vojtěch Šimetka Tue 24 Apr 2018 2:37AM

Andrea, this has long been something I was hoping we can do. There is a lot of reasons you have mentioned why this is good idea and I am fully onboard. I've tried to do that some time ago a little by extracting the DAC, Campaign and User as models and services. The next step would be to do the same for other entities like Milestones or Donations (lets talk about it in the next meeting and wait after the bridge is deployed). The aim was to add all the functionality that is missing now and then stop adding new features, review the DApp, start doing rewrites and showing it to charities and projects. Just like it is described in https://wiki.giveth.io/documentation/DApp/product-roadmap/ . I really like unidirectional flow, so for me something like redux is very appealing. So far, we preliminarily agreed to use Context API instead. If you want to start tackling hard stuff like this, may I suggest writing jest tests for the already existing models/services? Actually, is there a better way to do these?

AA

Andrea Ascari Tue 24 Apr 2018 9:54AM

I haven't tried the new context API yet, but I can say there's no reason to reinvent the wheel and create our own state-management solution on top of context API.
What I was thinking, as initial step, is to move out the logic from components and create containers, whom are responsible to connect to the state and define "actions" and leave just the UI inside the (dummy) components.
Of course it requires to write tests for the features we have atm, but maybe e2e tests are more appropriate in this case, as a lot of components are more likely going to change, while the flows should remain the same.

That being said, I used mobx for the last 4 months and I'm quite happy with that, but maybe the solution created by my ex-colleagues is still better: https://github.com/buildo/avenger (it also implements a level of caching and it's type safe).

Personally, I wouldn't go for Redux, cause I think it's too much boilerplate and just to run define a single reducer or action, while the 2 solutions I proposed above keeps things clear, with minimal boilerplate code and works with observers. And for the optimal solution I would build part of the logic with some functional concepts like Option, Either and Task.