Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Jul 20 23:24

    jdubray on master

    Adds todomvc-app-angular Adds todomvc-app-angular Adds … (compare)

  • Jul 20 23:24
    jdubray closed #9
  • Jul 20 23:21
    jdubray opened #9
  • Jul 20 23:21

    jdubray on todomvc-app-angular

    Adds todomvc-app-angular (compare)

  • Jul 19 11:06

    jdubray on master

    Small optimization (compare)

  • Jul 19 02:42

    jdubray on vue-todo-app

    (compare)

  • Jul 19 02:42

    jdubray on master

    Refactors the acceptors to use … Refactors the acceptors to use … (compare)

  • Jul 19 02:42
    jdubray closed #8
  • Jul 19 02:42
    jdubray opened #8
  • Jul 19 02:06

    jdubray on vue-todo-app

    Refactors the acceptors to use … (compare)

  • Jul 19 00:32

    jdubray on master

    Adds todomvc-app-vue sample Fixes the checked defect Adds missing files and 3 more (compare)

  • Jul 19 00:32
    jdubray closed #7
  • Jul 19 00:30
    jdubray synchronize #7
  • Jul 19 00:30

    jdubray on vue-todo-app

    Adds methods to edit the task's… (compare)

  • Jul 17 05:03
    jdubray synchronize #7
  • Jul 17 05:03

    jdubray on vue-todo-app

    Cleans up the code (compare)

  • Jul 17 05:00
    jdubray synchronize #7
  • Jul 17 05:00

    jdubray on vue-todo-app

    Adds missing files (compare)

  • Jul 17 04:56
    jdubray synchronize #7
  • Jul 17 04:56

    jdubray on vue-todo-app

    Fixes the checked defect (compare)

Michael Chisari
@michaelchisari
Yeah, I built the reject and accept as very specific functions.
Also, I'm trying to learn this because I'm interested in seeing if I can apply this to Dart/Flutter. I think there's potential there.
Jean-Jacques Dubray
@metapgmr_twitter
You should be able to, there is nothing specific to javascript. At a high level that's really all you need.
An action would look like this:
const action1 = (a,b,c) => {
      // create / compute / fetch the proposal
      return { a, b, c }
}
then you wrap actions into something like this:
const intentFactory = (model, action) => (...args) =>  {
             model.present(actions(...args) )
}

const intent1 = intentFactory(model, action1)
then you can call intent1(a,b,c)
Jean-Jacques Dubray
@metapgmr_twitter
There is really nothing more to SAM. Perhaps, just nap (next-action-predicate). This is just used to trigger automatic actions once the mutation has completed.
From my experience, it's a very logical way to decompose your business logic and in particular, decouple it from the view.
Michael Chisari
@michaelchisari
So far that's what I really like about SAM, it's a very straight-forward pattern.
Jean-Jacques Dubray
@metapgmr_twitter
Even writing the sam-pattern library was very straightforward. There is really no magic to it.
It's not too different from other paradigm say like Redux or Elm, but the main difference is on the emphasis on giving more responsibilities to actions (computing/preparing the proposal) while Redux and Elm tend to have anemic actions that are just a data object.
Then there is also the many-to-many relationship between actions and acceptors (an action's proposal can trigger mutiple acceptors and multiple actions can trigger the same acceptor).
Lastly, there are reactors that "react" to mutations. All these concepts are in redux, but the emphasis on how to use them is very different.
Michael Chisari
@michaelchisari
Right, I actually found out about SAM originally through Elm's approach which I def prefer to MVC/MVVM/etc., but still didn't seem quite there.
Jean-Jacques Dubray
@metapgmr_twitter
The next-actions are not in redux and people have been using sagas, most people don't like sagas. next-actions tend to be more natural and they do not have their own state, unlike saga.
What I don't like about Redux and Elm is that the logic is concentrated in a single reducer and actions are just data object.
IMHO, that's why people complain about Redux, for real world application, that's just not the right thing to do. But again, that's just a style, you could choose a style that's closer to SAM. It would be harder with Elm, as I understand it.
Fred Daoud
@foxdonut
What is the difference between an acceptor and a reactor?
Jean-Jacques Dubray
@metapgmr_twitter
An acceptor would mutate the state, the reactor would react to the mutation calculating computed values (technically a mutation, but automatic mutation). For instance, you could have an action that changes the settings of a thermostat. The inner workings of the system are using Celcius, but the user has chosen to display the temperatures (setting, measured value...) in Farenheight. A reactor would compute the resulting Farenheight values, while the reactor will do all the checks to see if the new setting is valid and decide to accept it or reject it.
The idea behind SAM is to isolate mutations to their lowest form, unencumbered by the pre-calculations of the proposal and the post-calculations of computed results (while putting the mutations in a critical section).
Fred Daoud
@foxdonut
I see, thanks for the explanation :thumbsup:
Michael Chisari
@michaelchisari
@metapgmr_twitter Do you mean the reactor would compute the resulting F° values, while the acceptor does all the checks and accepts/rejects it?
Fred Daoud
@foxdonut
In Meiosis this is slightly different, in that mutation happens automatically, BUT acceptors look at the state and make any further changes to produce the accepted state. So, nothing else sees the state until the acceptors have done their work. There is no formal distinction between an acceptor that alters the state (equivalent of rejecting or altering a proposal) and an acceptor that produces computed values.
Jean-Jacques Dubray
@metapgmr_twitter
@michaelchisari yes, correct.
Again, the idea is to keep the mutation code to a minimum to be able to reason clearly about it. Nothing magical about it. Just making mutations a first-class citizen of the programming model, as acceptors.
Paolo Furini
@pfurini
A client of mine is pushing flutter for a mobile app project.. if it wins over my recommendations, I’d like to try porting the Sam library to dart, and see how it fits in flutter. I don’t like the state management in flutter, but maybe there’s some hope with SAM (plus I’ll need to explain it to my client)
Jean-Jacques Dubray
@metapgmr_twitter
:+1:
Michael Chisari
@michaelchisari
Dart/Flutter + SAM seems like a potentially very powerful combination.
RayoGundead
@RayoGundead
Dart has streams
that's one big plus if you prefer wiring it up via observables/streams
Paolo Furini
@pfurini
Flutter has the same issues with SAM as those with Angular.. it’s not pure reactive, so to compute the new view you can’t just recreate it like you do in lit html or React (sort of)
I don’t like such binding approaches anymore, they’re just cumbersome to deal with
Jean-Jacques Dubray
@metapgmr_twitter
:+1:
Jean-Jacques Dubray
@metapgmr_twitter
Jean-Jacques Dubray
@metapgmr_twitter
So I started to write more golang, not sure I ever dislike a language so much.
Paolo Furini
@pfurini
🤣
Paolo Furini
@pfurini
PS: despite some weird choices in its grammar, golang proves to be a perfect fit in many situations. I don't know how it scales when used for web or API development, but it's super useful in devops and systems programming, and I use it for backup scripts, notification scripts, daemons/services and so on
being able to cross-compile everything with a single command, it's a real time saver (when you have a mixed farm of linux and windows servers, plus macos clients)
Jean-Jacques Dubray
@metapgmr_twitter
I was purely talking about the language, oh my... not sure where to start, my eyes are still flashing at all the error handling and my mind is still cramped to understand what's inferred from what's declared in the language. I love the json annotations though, just kidding.
Million dollar question: how much boilerplate can be avoided when a language adopts a JSON like construct (with destructuring and optional-chaining)?
Michael Chisari
@michaelchisari
SAM seems to work best with UI frameworks that very selectively update. React is good, lit-html is even better. But for instance, Dart/Flutter (and SwiftUI and Jetpack Compose) doesn’t have anything similar to dom-diffing which can determine what in the tree has changed and only update the changes. Which requires more fine-grained listeners for changes for performance.
Is this other people’s experience?
Michael Chisari
@michaelchisari
Looks like SwiftUI does do optimized diffing of the tree, actually
Flutter says it does optimizations but everything seems to recommend against forcing a top-level UI rebuild using setState on the top widget.
Michael Chisari
@michaelchisari
I’ll have to do more research to see whether state changes prompting a full rebuild is a viable approach on these platforms.
Jean-Jacques Dubray
@metapgmr_twitter
What is true is that the greater the area rendered by a functional approach the more it will flicker. Hence to apply that kind of approach you need to be selective as to how much you render, hence these diffing approaches (react, lit...). That is not inherent to SAM. I have implemented SAM with vanilla.js and dividing the area in "sections" (3 sections: header, page, footer) and it looks just as good as React (of course not for arbitrary complex UIs). I am just trying to make the point that very simple approaches makes is possible.
Michael Chisari
@michaelchisari
Right, it’s not inherent to SAM, but when there is a highly efficient diffing approach, implementing SAM seems easier since the diffing takes care of any inefficiencies on re-render, and it scales to complex UIs without additional work.
Jean-Jacques Dubray
@metapgmr_twitter
Algebraic effects: you don't like my proposal? you get a second chance, try another one! https://overreacted.io/algebraic-effects-for-the-rest-of-us/
As you can imagine, I find this suggestion as ludicrous as it could be. Not surprisingly it comes from FP... (face palm). I much prefer a programming model where mutations are first class citizen and proposals are partially accepted or rejected which lead to clear next-actions that may be triggered to generate a new proposal. Sprinkling your code with random next actions and on the spot acceptors without a clear step is a recipe for disaster.
Jean-Jacques Dubray
@metapgmr_twitter