Comment by disantlor | Hacker News Reader

Comment by disantlor | Hacker News Reader

Parent Full thread

Discovering and mastering bacon.js/FRP completely changed the way I think about programming. It hugely increased the quality and stability of my code in ways that continue to surprise and amaze me. I cannot recommend it enough, but this article definitely has me curious about ClojureScript.

In the meantime, the biggest issue I've had with bacon is figuring out what are the best practices in organizing the code. One does end up with a lot of streams or variations/combinations on streams used for different purposes. Eventually it does become hard to follow, as the author mentions, though because all state is self-contained you can change any one part with a high degree of confidence that it won't break other features.

Still there must be some ideas out there that don't involve incorporating a full blown framework/SPA architecture. The author of bacon has a blog post on the subject but it seemed to me that there could be better ways still. Anyone have any suggestions?

I wrote a 20k LoC bacon app in 2014 and had the same issue with being able to understand all the pieces individually but having trouble comprehending the whole system.

I don't have non-architecture answers for how to organize code since that's pretty much the point of an architecture. Most of the application organization patterns around the React space are only ~200 lines of code and a description of how the pieces fit together. You don't have to adopt the whole thing immediately but you don't get the full benefits of a pattern until everything works the same way.

For my part, I got a job writing clojurescript full time and migrated the app to re-frame [1][2] this year in pieces over the course of a couple months and it's the first frontend architecture that's made me happy in over a decade of continuous searching. The js version is Redux but I think Redux is missing middleware as a concept.

[1] https://github.com/Day8/re-frame/ [2] https://github.com/binaryage/pure-frame <- Fork with no global atom

What this provides is a complete event cycle of completely pure functions (the state swap happens in the framework) with all the data in an immutable map in a single atom. By namespacing my subscriptions and events I can see a problem, look at the component, and know immediately where my problem is within ~10 lines of code. It's not perfect but it's pretty good.

One thing that doesn't get mentioned often enough when talking about Clojurescript is the potential for doing server-side rendering of the app without having to run node. [3]

[3] http://yogthos.net/posts/2015-11-24-Serverside-Reagent.html

> The js version is Redux but I think Redux is missing middleware as a concept.

Redux totally has middleware (you actually need middleware for async actions).

Happy to hear that. I'm not actively using it and I find the the docs are fairly good but written from the implementor's perspective so they tend to bury the lede. I didn't think it had the equvalent of Reagent's reactions until I got towards the bottom of the react-redux page, which was the third or fourth time I looked at the docs. I'm not sure if I just missed it or it got added after I last looked.

I started recently, but I find them fairly decent. And there is not much to it, really.

> I didn't think it had the equvalent of Reagent's reactions until I got towards the bottom of the react-redux page

Is that the subscription mechanism? I have yet to find a use for it...

> And there is not much to it, really.

The two use the same model but are organized differently so it throws me off a bit.

Re-frame chooses to hide the actual reduction step so instead of the big switch statement you have a bunch of registered event handlers, which are pure functions take the state and event and return the new state. The middleware is HoF around these so it's done per-handler as well as at the base reducer level, which turns out to be really good for code reuse.

> Is that the subscription mechanism? I have yet to find a use for it...

I think they call it selections. Reactions let you transform a normalized data model into a shape that's useful for the components. They also let you build up chains of reusable calculations/conditions to shift complex conditionals out of the components and into the model code so its co-located with the handlers, which are split up by the part of the app they work with (credentials, search, nav, etc).

This sounds like an interesting approach, though I'm not really fan of events (it's easy to see when they fire, but less easy to make sure anything is listening).

You could try applying The Elm Architecture [1]. It's developed for the Elm programming language [2], but I've seen more than one framework outside of the Elm ecosystem cite it as inspiration for their structure.

[1] https://github.com/evancz/elm-architecture-tutorial/ [2] http://elm-lang.org/

CycleJS, which is based on RxJS and smaller than most of the "full blown" frameworks and SPAs, I think has a good approach to code organization in its MVI (Model-View-Intent) documentation:

http://cycle.js.org/model-view-intent.html

For a couple of projects I'm working on I've been slowly iterating towards one sort of deeper formalization of Cycle's MVI, but I haven't published any of that work yet.

Loving cycle.js so far, thanks for the tip!

I wrote a post on using RxJS as a model layer with React a while ago (http://aricedev.com/building-a-model-layer-with-rxjs/). The biggest change I've made since then, aside from moving to immutable data structures, is that I'm using a single Rx subject in each store to delegate to the appropriate streams instead of having a subject for each stream.

You should look into Cycle.js[1] to better organize front-end FRP applications.

[1] http://cycle.js.org/

Reply on news.ycombinator.com