Hacker News Reader

Comment by thrashh | Hacker News Reader

What had always worked for me is that I write the web app as regular classes / objects, make it observable with mobx, then add React as essentially a template library — like as if it was mustache.js or something.

The non-React code works on its own and is super easy to understand. You could even extract the business logic and make it a CLI or a reusable library.

Shit, all my apps - Java, C++, whatever - have always been structured like this: domain logic + a decoupled frontend. I pretty much only adopt libraries that match my way. Redux did not match my way

My coworkers from past jobs tell me the way I structure my projects is so clear so I think I’m on the right track

View on HN

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 :)

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.

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 ):

I don’t understand why people moved away from this. It doesn’t even have to be mobx’d ideally, an informal emitter protocol would be fine, just as “rerender all reconcile the changes” mode for pages with 10k divs or less. People use a concept-heavy application framework and pretend it’s “just a thin ui library” because kilobytes. Absurdity.

I've done similar! Worth checking out googles lit-html if you want just a template library.

Reply on news.ycombinator.com