I would like to amend this: don't use Redux until you have problems with vanilla React. - Dan Abramov
Dan said this way back in 2016, and now th...
For further actions, you may consider blocking this person and/or reporting abuse
Hello, look at the Meiosis pattern.
Regards
Search Meiosis on Dev to
First time I hear about it: dev.to/artydev/frontend-state-mana...
The explanations are terse, but yes I saw this:
meiosis.js.org/
"Think Redux, MobX, Cerebral, React Context, etc. but without having library imports everywhere and being tied to a framework API. Instead, just plain functions and objects. All you need is a simple stream library such as Flyd or Mithril Stream"
So you don't need to have library imports ... but you do need a library ;)
No :-)
All you need is two streams functions map and scan that you can implement yourself or use the simple implementation mithril-stream
And the function I use to merge states is a thirty lines of code called mergerino, which extends Object.assign.
I would not call them library, they are so tiny and very specialised
You can use whathever you want for the view (event document.innerHTML)
Here I use JQuery
MeiosisJS
Look at this for a starting pont :
observables
Regards
code for mergerino
the code of mithril-stream is here from Isiah Meadows Mithril's maintener.
So you need to learn how think in terms of streams and observables (I think RxJS is a famous library in this area) ... if you're not familiar with that paradigm yet then it's definitely a learning curve compared to the way you'd normally do things with Redux or Context.
Think of streams as Excel cells and you will have a good starting point.
I have written a few lines as introduction here
streams
You absolutely don't need RxJS, as I said earlier you only need map and scan for Meiosis
Here is very simple stream implementaion with a map function :
You can test it here :
StreamMap
Regards
Thanks, excellent, yes I get the idea ... I only mentioned RxJS because that's how I ever heard about streams and observables :-)
So can I put it like this: Streams provide a different approach (paradigm, if you will) to working with state in an "immutable" way?
Because that's basically what Redux and Context (and all of React, for that matter) tell us:
Do NOT modify state directly - return a new copy of your state, so treat it as 'immutable' ... streams do just that, but in a different (and probably easier or more powerful) way.
:-)
I am in favor of simplicity, If you are creating a project for your own needs, you really don't need heavy tools.
Use Meiosis with whatever view library you want or nothing eventually.
May I suggest you to use Mithril ?, simple, light and a very kind community :-)
Regards
I've heard about Mithril, but I also heard that Svelte is the greatest thing since sliced bread ... can you compare those two?
Much has been said on Svelte the "javascript compiler".
I can only agree with the speed and tiny apps it produces.
But for my needs I don't see what it brings more than Mithril
Mithril is only Javascript, with Svelte you have to learn a new syntax,
and you can't start without tooling, so integrate it into existing applications is not obvious
For example I needed to extends functionality to an Editor by adding a 'photo' button
with Mithril it was a piece of cake, It would not been that easier with Svelte.
JoditMithril
The more you use Mithril the more you know Javascript, I am not sure this is the case for all the well known frameworks
Right, yes I understand that they're different philosophies, more or less the opposite ...
Mithril is something you can drop into an existing page to enhance it, Svelte is more something you use to build a complete standalone app, it doesn't easily integrate, and it introduces its own tooling and syntax (a bit comparable with Vue with its template syntax, while React takes pride in sticking closer to standard JS, at least that's what it claims).
Totally different beasts really :-)
:-) you can also build complete apps with Mithril.
Among Mithril's users Nike.
Look carefully to this page :-)
Who use Mithril
Regards
Yeah. Looks similar.
Good explanation, but I can't help but notice how similar the code looks compared to what you would write if you use Redux - you still write reducers, actions, dispatch, etcetera ... so, I could be wrong, but at first sight we don't seem to have gained much in terms of reducing boilerplate.
The only simplification then seems to be that we can omit one or two dependencies from our package.json (but Redux doesn't add that much to the bundle size, it's a pretty small library).
Note that I'm not saying that this approach (Context) is worse than using Redux, but I also don't see immediately how it's better or simpler - the way you manage state with Context is largely the same.
Or am I missing something?
You are right. I never considered "reducing boilerplate" as a goal. I wanted to show that we can achieve redux like functionality in vanilla react itself.
Understood ... but look at this one - we might not need Redux, but we might even also not need Context! dev.to/g_abud/why-i-quit-redux-1knl
Sure will check it outβπ½
Really nice introduction to Context. Is there a well-established way to use asynchronous actions, similar to redux thunk?
You can declare an async function in the value prop to the Provider. Here's an example: codesandbox
P.S. Not sure if this exactly what you asked for.
Yes, this is it. It occurred to me when I saw the example that I don't need middleware to access state - here I can simply refer to it if I need for example some intersection between fetched data and current state.
Thank you :-)
You're welcomeππ½
It was! Thanks mate :)
Glad you liked it.