2 ms·

I think that arch is the best and I've used it for low interactivity projects where the frontend is almost all display. Haven't tried it for complicated SPAs wi

by ht85 4y ago

I think that arch is the best and I've used it for low interactivity projects where the frontend is almost all display. Haven't tried it for complicated SPAs with lots of DOM interaction though. Do you have any such experience? How do you architecture your models, events, processing, updating, etc? Do you have UI-less component-like pieces of code that you can compose? Or a fat root state manager that does everything? Not sure if you work on any public repos, would love to have a look if you do for inspiration :)

Rapzid 4y ago
Stores for everything. Modal stores; enforce open modal business logic app wide. Menu stores; allow customizing menus via config or plugins. Event store; app wide event bus now you can know when specific components/widgets rendered for the user. Theme store; wrap light/dark media query for system pref and user override in an observable. Keep any and all business logic out of components if at all possible; that's my moto.
thrashh 4y ago
I don’t have a repo to show but I’ll try my best to explain First I want to note that I do use React hooks. If I can some UI code in React, I will. DOM code would go in React I just won’t put business logic in React ever. No non-UI side effects and no external state are allowed in my hooks I still want my React components themselves to be a reusable library. My applications are basically a reusable logic library coupled with a reusable UI library. It’s that division that makes this style easy to read - your brain is either in UI mode or business logic mode. You never confuse yourself trying to figure out what it’s doing because you can just read one side and ignore the other Whether you use a fat root state or not is honestly up to you. It’s really the separation that is key I’d check out mobx examples I know that’s not super specific and there are edge cases that you’ll run into, but my public repos are either Java and non-UI JS libraries ):

by ht85 4y ago

Rapzid 4y ago

Stores for everything. Modal stores; enforce open modal business logic app wide. Menu stores; allow customizing menus via config or plugins. Event store; app wide event bus now you can know when specific components/widgets rendered for the user. Theme store; wrap light/dark media query for system pref and user override in an observable. Keep any and all business logic out of components if at all possible; that's my moto.

thrashh 4y ago

I don’t have a repo to show but I’ll try my best to explain First I want to note that I do use React hooks. If I can some UI code in React, I will. DOM code would go in React I just won’t put business logic in React ever. No non-UI side effects and no external state are allowed in my hooks I still want my React components themselves to be a reusable library. My applications are basically a reusable logic library coupled with a reusable UI library. It’s that division that makes this style easy to read - your brain is either in UI mode or business logic mode. You never confuse yourself trying to figure out what it’s doing because you can just read one side and ignore the other Whether you use a fat root state or not is honestly up to you. It’s really the separation that is key I’d check out mobx examples I know that’s not super specific and there are edge cases that you’ll run into, but my public repos are either Java and non-UI JS libraries ):