SAM pattern?

[qur2]

Hi,

I went through you tutorial and I like how it shows that you don't need much to build an app with modern ideas (view = f(model)). Especially, whatever rendering lib you use, it does not really matter :)

However, I knew meiosis before as a "framework" implementing the SAM pattern (https://foxdonut.gitbooks.io/meiosis-guide/content/sam.html). This part is missing from the tutorial. I'm wondering what's the relation between your previous gitbook and this tutorial. Do you intend to add state + model + next action predicate in that? It would be nice to show how to implement the SAM pattern as an extension to the meiosis pattern.

Just my thoughts, take it or leave it :)
PS: I'm also very eager to see / try to write an example with SAM and Reasonml, as the pattern matching would work really nicely with that, I believe.

[foxdonut]

Hi @qur2

Thanks for your interest in Meiosis, I appreciate it :-)

As you said, the previous version of Meiosis was a library or small framework aiming to implement SAM. Later, I chipped away at the code and the concepts. I had less and less code until I ended up with practically no code at all! That became the Meiosis pattern.

I believe what makes Meiosis unique and compelling is precisely that it's not a library but a powerful and flexible pattern that you can use and adapt to your needs and requirements.

That being said, the relationship to SAM is not as direct as it was. Meiosis is its own pattern. It can be used to implement SAM but it can also be used without necessarily corresponding to SAM. For example, you can use Meiosis without needing proposals, and also without nap().

On the other hand, you can implement those parts of SAM using Meiosis: this example has a more formal propose/accept structure, and this example has nap(). I haven't put these in the "main" Meiosis Tutorial or Documentation because in most use cases that I've come across, the Meiosis pattern solves the problem with less code. Of course, that does not stop you from implementing SAM with Meiosis, as shown in the examples above.

I hope that answers your questions, let me know if I can be of further help.

[qur2]

Many thanks for the feedback. I've translated a bucklescript example to reason: https://github.com/qur2/reason-tea-sam
I've also enjoyed your basic examples with parceljs (feels so lightweight!)

Next is to investigate the 2 links you've posted and grow both my playgrounds. I'll report with the outcome here (hopefully in the form of some repo).

In the meantime, I have one more question: what sets the meiosis pattern apart from TEA?

Have a nice weekend!

[foxdonut]

@qur2 good to hear! 👍

In the meantime, I have one more question: what sets the meiosis pattern apart from TEA?

I think one major difference with TEA (and Redux) is that Meiosis doesn't require you to come up with names and constants for all the different types of actions of your application. Furthermore, you don't need switch/case statements, if/else statements, or other branching code that needs to look at the type of action and then decide what to do. Personally I find that this reduces considerably the amount of code and effort required as you build your application.

Another difference is with asynchronous actions, side effects, and so on. In Meiosis, you just perform those normally, then call update(...) when it's time to update the application state and (automatically) re-render the view. TEA, I believe, requires you to use Effects or similar specific type and mechanism for side effects. The Meiosis pattern doesn't impose anything on you, and I think this gives you more flexibility.