4 ms·

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 th

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?

Apanatshka 11y ago
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/ https://github.com/evancz/elm-architecture-tutorial/ [2] http://elm-lang.org/ http://elm-lang.org/
grayrest 11y ago
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/ https://github.com/Day8/re-frame/ [2] https://github.com/binaryage/pure-frame 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 http://yogthos.net/posts/2015-11-24-Serverside-Reagent.html
- mercurial 11y ago
  > 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).
  - grayrest 11y ago
    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.
    - mercurial 11y ago
      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...
      - grayrest 11y ago
        > 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).
adrice727 11y ago
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/ 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.
WorldMaker 11y ago
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 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.
- disantlor 11y ago
  Loving cycle.js so far, thanks for the tip!
sotojuan 11y ago
You should look into Cycle.js[1] to better organize front-end FRP applications. [1] http://cycle.js.org/ http://cycle.js.org/

Apanatshka 11y ago

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/ https://github.com/evancz/elm-architecture-tutorial/ [2] http://elm-lang.org/ http://elm-lang.org/

grayrest 11y ago

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/ https://github.com/Day8/re-frame/ [2] https://github.com/binaryage/pure-frame 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 http://yogthos.net/posts/2015-11-24-Serverside-Reagent.html

mercurial 11y ago
> 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).
- grayrest 11y ago
  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.
  - mercurial 11y ago
    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...
    - grayrest 11y ago
      > 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).

adrice727 11y ago

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/ 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.

WorldMaker 11y ago

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 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.

disantlor 11y ago
Loving cycle.js so far, thanks for the tip!

sotojuan 11y ago

You should look into Cycle.js[1] to better organize front-end FRP applications. [1] http://cycle.js.org/ http://cycle.js.org/