Very informative, thank you! /* One thing though. It was kind of pity that you didn't switch from the Counter page to another page and back again to show that the state really was stored as that was the goal for the session. I suppose the timeline was evidence enough... ;) */
Yes I should've shown the other page to show the state persistency.... But you're right, the timeline should demonstrate that Fluxor saved the information - including the history ;)
This pattern works and it really makes complexer web apps function properly. However, there are two counter-intuitive things here which should be adressed. The first is the term "reducer" which is not intuitive. From a theoretical informatics standpoint two inputs are reduced to one output yes, but in practice this makes no sense. What if I want to add like in this example? So the "reducer" does "add"... that is not reducing, that is adding. So it is actually not a reducer at all but more of a state transformer or processor. The term reducer should be removed from this pattern and be replaced with something intuitive. 2nd the action (AddCounter) is defined as a record... yet that record is never used. The action is purely a token object, it could as well be a string or whatever. Using a record is counter-intuitive. It makes people think that this record has a meaning and that it could comtain data. In my opinion actions should be Enums and these enums should represent the collection of actions which are possible on a specific store. Modeled that way, the pattern would be more understandable and intuitive to apply in practice.
Nice Video Chris Thank you! I wanted to ask why not the action is the one who is holding the new state, so in the reducer instead of 'old_state' = 'old_sate' + 1, we write 'old_sate' = 'action.new_state'. Or Did i understand the fluxor pattern wrong?
A very interesting question! The scenario that you're describing is 100% legit - and you can have both your scenario and the one in the video inside your reducer. In your described scenario, we set the reducer function to make the last action always win. We would want to have logic in an event where we have multiple actions firing at the same time and we want the final action to be the output of this event. Example: auto-search while typing. In another event where we fire an action to modify the current state (i.e. incrementing your state), then we want the reducer to simply read the current state, and then modify the state accordingly. Example: counter in the video. The Fluxor's reducer provides you with both current state and your action data - whichever you pick should be the one that is most suitable for your use case. :) Cheers! - Chris.
Actually, this confused me a lot as I watched this video to learn how to use Fluxor, I had to dig into the official documentation to get an idea of why was my state not being updated.
lets use Fluxor to avoid boiler-plate code and let's add bunch of extra files and code which is already working with 2 lines of code. if state need to preserved then a simple service injected with built-in DI in Blazor isn't sufficient?
Interesting demo thanks. Chris you were complaining about Blazor not supporting LESS/SCSS however it does not need to. You can just add those files .razor.scss And you can use a VS extension (probably VS Code has the same) called WebCompiler. Which is automatically detecting any changes and able to "compile" LESS/SCCS file to CSS and min.css files. So you write your stile in SCSS and Blazor will use the compiles CSS. Basically the same things apply on TypeScript/JS. You can add and write TypeScripts instead of JS files. And use a compile/transpile tool which converts .ts into .js and min.js... All works perfectly.
These videos are good and informational, I just can't figure out why he randomly starts making his own voice crack and jump to a high note at the very end of his sentence, lol, it's very strange. "We had an issue ... on our GitHub _pAGE_ ..." haha, it's the last syllable of a sentence, he stops doing it for a minute and then starts again heavily 😆
Another example of how JS paradigms ruin c# world. How overcomplicated, just for one counter, imagine a whole application :S. Godness!! why people overcomplicate things. The unique nice feature of using redux is the time travel, the rest can be done without that much boilerplate. Maybe Mobx paradigm would be a better fit for C#, and way more simple and performant.
Why would you need to save the form in a State?, if its to save it, I would implement localStorage on that form only apart from the Store. In the apps I've worked on, we only use the result of a form into the Store. Guess you can do it if you want with OnChanged events for everything, but isn't that overcomplicating things?
![[Full] 4 ต่อ 4 Celebrity EP.910 | 22 ก.ย. 67 | one31](http://i.ytimg.com/vi/4TR3MVpOiw8/mqdefault.jpg)
Another counter demo yeeaaayy :) 🤘
Very informative, thank you!
/* One thing though. It was kind of pity that you didn't switch from the Counter page to another page and back again to show that the state really was stored as that was the goal for the session. I suppose the timeline was evidence enough... ;) */
Yes I should've shown the other page to show the state persistency.... But you're right, the timeline should demonstrate that Fluxor saved the information - including the history ;)
@@chris.clement Besides Fluxor, timeline was a great experience that I didn't know of. Thanks again.
Nice talk!
This pattern works and it really makes complexer web apps function properly. However, there are two counter-intuitive things here which should be adressed. The first is the term "reducer" which is not intuitive. From a theoretical informatics standpoint two inputs are reduced to one output yes, but in practice this makes no sense. What if I want to add like in this example? So the "reducer" does "add"... that is not reducing, that is adding. So it is actually not a reducer at all but more of a state transformer or processor. The term reducer should be removed from this pattern and be replaced with something intuitive. 2nd the action (AddCounter) is defined as a record... yet that record is never used. The action is purely a token object, it could as well be a string or whatever. Using a record is counter-intuitive. It makes people think that this record has a meaning and that it could comtain data. In my opinion actions should be Enums and these enums should represent the collection of actions which are possible on a specific store. Modeled that way, the pattern would be more understandable and intuitive to apply in practice.
Nice Video Chris Thank you!
I wanted to ask why not the action is the one who is holding the new state, so in the reducer instead of 'old_state' = 'old_sate' + 1, we write 'old_sate' = 'action.new_state'. Or Did i understand the fluxor pattern wrong?
A very interesting question!
The scenario that you're describing is 100% legit - and you can have both your scenario and the one in the video inside your reducer.
In your described scenario, we set the reducer function to make the last action always win. We would want to have logic in an event where we have multiple actions firing at the same time and we want the final action to be the output of this event. Example: auto-search while typing.
In another event where we fire an action to modify the current state (i.e. incrementing your state), then we want the reducer to simply read the current state, and then modify the state accordingly. Example: counter in the video.
The Fluxor's reducer provides you with both current state and your action data - whichever you pick should be the one that is most suitable for your use case. :)
Cheers!
- Chris.
Actually, this confused me a lot as I watched this video to learn how to use Fluxor, I had to dig into the official documentation to get an idea of why was my state not being updated.
Awesome work Chris! 🤟
lets use Fluxor to avoid boiler-plate code and let's add bunch of extra files and code which is already working with 2 lines of code. if state need to preserved then a simple service injected with built-in DI in Blazor isn't sufficient?
This is so cool that even though Fluxor is overkill for my Blazor app, I have to dd it.
Good demo
Excellent ! Really like this...
Great demo 😊
Interesting demo thanks. Chris you were complaining about Blazor not supporting LESS/SCSS however it does not need to. You can just add those files .razor.scss And you can use a VS extension (probably VS Code has the same) called WebCompiler. Which is automatically detecting any changes and able to "compile" LESS/SCCS file to CSS and min.css files. So you write your stile in SCSS and Blazor will use the compiles CSS.
Basically the same things apply on TypeScript/JS. You can add and write TypeScripts instead of JS files. And use a compile/transpile tool which converts .ts into .js and min.js... All works perfectly.
This is nice. Thanks!
Hi;
Can you tell us, what tools we need to install in Chrome to be able to use the Redux tracking?
These videos are good and informational, I just can't figure out why he randomly starts making his own voice crack and jump to a high note at the very end of his sentence, lol, it's very strange. "We had an issue ... on our GitHub _pAGE_ ..." haha, it's the last syllable of a sentence, he stops doing it for a minute and then starts again heavily 😆
169 stars? Nice
Another example of how JS paradigms ruin c# world. How overcomplicated, just for one counter, imagine a whole application :S. Godness!! why people overcomplicate things. The unique nice feature of using redux is the time travel, the rest can be done without that much boilerplate.
Maybe Mobx paradigm would be a better fit for C#, and way more simple and performant.
What would be very useful would be an example of a form. I don't understand why EVERYONE demonstrating fluxor takes the counter example.
Why would you need to save the form in a State?, if its to save it, I would implement localStorage on that form only apart from the Store. In the apps I've worked on, we only use the result of a form into the Store.
Guess you can do it if you want with OnChanged events for everything, but isn't that overcomplicating things?
presentation's code at: github.com/christoment/BlazorWithRedux
Anyone else stuck on th-cam.com/video/sAyH-O0dFaI/w-d-xo.html and thought how can this work? And then... th-cam.com/video/sAyH-O0dFaI/w-d-xo.html :D
yup
Ouch, that was just painful to watch.