Comment by hcarvalhoalves | Hacker News Reader

Comment by hcarvalhoalves | Hacker News Reader

> As more and more developers start to see the advantages of components and unidirectional architectures, the focus will be on building better tools and libraries that go down that path.

"Unidirectional architecture" is a weird name for what is a fairly standard abstraction. Every front-end at the top level is:

    f(my_entire_state, some_event) -> my_entire_state'

In the end all you need are well defined state transitions, an event bus and a main loop to connect the two. Persist the sequence of events for undo/redo, audit, debugging ... and the current state for caching or having durability between sessions. Push side-effects to the boundaries. You may find this is good enough.

Front-end development has been plagued by unclear patterns w/ weird names (MVC, MVVM, MXYZ...) since forever; everytime the patterns are criticized you hear "you did not understand it"; and new names keep popping up. It seems the industry is stuck remixing reasoning around nouns, and is unable to step back and reason around data.

BONUS: Sprinkle some CSP to get elegant concurrency, throw away callback-hell. Sprinkle some React to get fast DOM manipulation, throw away Flux (heresy!) - it has way too many names to worry about (action creator, action, dispatcher, callbacks, stores, store events, views) and encourages some bad practices around use of stores.

My $ 0.02

The CSP thing is something I've been looking at recently, and while it seems like it's a little bit lower-level than things like Rx, it seems like channels are more flexible streams (i.e. channels are two-way so you can do back-pressure etc.). I've been playing with https://github.com/ubolonton/js-csp and it's pretty nice; the "yield" statements everywhere are a little wonky, but otherwise it seems like you can implement some pretty sophisticated concurrency between processes with pretty straight-forward code.

For examples of that sort of thing, David Nolen and James Long have written some really great articles on the subject:

http://swannodette.github.io/2013/07/12/communicating-sequen...

http://swannodette.github.io/2013/07/31/extracting-processes

http://jlongster.com/Taming-the-Asynchronous-Beast-with-CSP-...

There was also an article recently that described a flux-like architecture using channels that I found pretty interesting, but I can't track it down right now.

Those articles are excellent and held my interest since they were published, but at the same time React and Flux were exploding and I never saw any further talk of modeling UI logic with processes and channels. It is still in my notes: Take another look at Hoare CSP for UI programming perspective. I once asked David Nolen on twitter if he thought the CSP approach is still useful given the perspective of React/Om. He said yes but that was the extent of the conversation.

In particular, I have yet to see any examples of integrating the CSP approach with React or similar architectures. For example, can you hook a process-based autocomplete widget into a React view? Is anyone doing this or have we rejected CSP for UI logic? I am interested if you can find article you mentioned.

David has moved away from it, in OM.next you do not use CPS. You can of course, but it would only be a implementation detail and not fundamental to the structure of Om.next.

I think that's what I'm driving at: apart of the Om architecture itself, does it make sense to drop something like a CSP autocompleter into an Om app, or are those things incompatible?

Well said! I find that https://github.com/Day8/re-frame combined with statecharts fits the bill and makes for some incredibly clean and enjoyable UI development.

How do you architect your re-frame apps? How do you decide where dispatch/subscribe gets called? I ask, because having worked on a couple of re-frame (and indeed raw reagent) projects, I often see issues of layering and responsibility that MVC traditionally solved.

For example, I regularly see subscriptions deeply nested in the component hierarchy, instead of more 'pure' components that just accept data at the top level. This leads to controller-style logic spread all over the app. I see the same issue with events - dispatch being called from inside view components, and despite the event abstraction, what you basically end up with is mutable state spread all over the app.

Happy to admit these apps probably aren't shining examples of react/reagent/re-frame architecture, but I'd be interested to see some canonical architecture guidance.

If the only tool you have…

Reply on news.ycombinator.com