reffects VS re-frame

There are tools that do this automatically, stryker[2] is one of them. When you run stryker, it will create many mutant versions of your production code, and run your tests for each mutant (that's how mutations are called in stryker's' documentation) version of the code. If your tests fail then the mutant is killed. If your tests passed, the mutant survived. Let's have a look at the the result of runnning stryker against reffects-store's code:

This article always reminds me of this excerpt from re-frame’s docs [0]:

> Now, you think and design abstractly for a living, and that repetition will feel uncomfortable. It will call to you like a Siren: "refaaaaactoooor meeeee". "Maaaake it DRYYYY". So here's my tip: tie yourself to the mast and sail on. That repetition is good. It is serving a purpose. Just sail on.

[0]: https://github.com/day8/re-frame/blob/master/docs/correcting...

* Single-Page App: shadow-cljs for the build concerns (https://github.com/thheller/shadow-cljs), Reagent with Re-frame for complex/large app (https://reagent-project.github.io and https://github.com/day8/re-frame). Even if we now prefer using HTMX (https://htmx.org) and server-side rendering (Hiccup way of manipulating HTML is just amazing, https://github.com/weavejester/hiccup).

Big and/or complete projects that use re-frame The main list: https://github.com/day8/re-frame/blob/master/docs/External-Resources.md

Reflet is a set of tools for building Re-frame + React based web apps with graph and non-graph data models. This includes:

https://github.com/day8/re-frame

Notably the author of re-frame has been weary of hooks.

I think that’s for a good reason. The approach in re frame feels like the best way to manage state so far for a react based app. Everything that changes state flows through an event. State can only be observed through subscriptions. Side effects are isolated to their own type of event. Debugging and testing are so straight forward with these concepts.

Redux got close but it has two problems in my mind. Like hooks, it encapsulates for no good reason. Put the state in one thing that you can observe holistically before and after pure events. It also has too much boiler plate.

The cljs stack I hear about a lot (and use) is ShadowCLJS with reagent (https://reagent-project.github.io/) and re-frame (https://day8.github.io/re-frame/). ShadowCLJS is more of a build tool, but is really well documented and easy to use. Reagent is basically react but a simpler API, and re-frame is a layer on top of that provides data subscriptions and event-handlers to manage app state. It's overkill for some apps but I find it's actually super easy to work with and not as much complexity as I thought.

For backend there is luminus (https://luminusweb.com/) or Kit (https://kit-clj.github.io/). They are basically project templates that wire together a ton of popular solutions for various things - database access, migrations, security, html templating, etc. Also includes frontend frameworks like re-frame if you want.

Reflet aims to be a natural progression on top of Re-frame to support complex, data driven requirements. In that sense, it is both easy to learn, but powerful. You could say it's sort of like Re-frame++ (or Fulcro for Re-frame). Its main design goals are:

At my current client we're working on having a frontend architecture for writing SPAs in JavaScript similar to re-frame's one: an event-driven bus with effects and coeffects for state management[1] (commands) and subscriptions using reselect's selectors (queries).

Some of us had worked with effects and coeffects before while developing SPAs with re-frame and had experienced how good it is. After working with re-frame, when you come to horizon, you realize how a good architecture can make a dramatic difference in clarity, testability, understandability and easiness of change.

https://youtu.be/geeK1-jjlhY (talk about an initial prototype with re-frame and the decision to do a rewrite in Clojure)