How do you preserve the UI state when a hot code push occurs?
While we’re on examples, how would you do the following in React. That is, display a list of names, be able to select one item and set its class to active, and have another component show information about the selection. I imagine you would use Redux (in this example they’re not that far from each other, but they could be).
I do it constantly for checking if LMB\Space\Enter was pressed on an element:
a($b= "click: signOut, keypress: signOut") Sign out
signOut: (event)->
#check for click\space\enter
if event.type is 'click' or event.which is 32 or event.which is 13
event.preventDefault()
Meteor.logout()
We’re talking about events, not true bindings. You should have been able to use multiple events in the first place.
Update viewmodel-debug to 2.6.2. So a($b= "'click keypress': signOut") Sign out now works.
Now please make the case for multiple bindings using the same predicate (be it a function or a value/object). I don’t want to do the lazy thing and just add the feature “because it’s not going to break anything if it isn’t used”.
Collection and Session hold the UI state across hot code pushes. Don’t get me wrong though, I think this is a really nice shortcut for Blaze templates! I bet there’s a different solution for React…
I remembered why I used the reactive-dict in the example as soon as I created a demo without it and updated it. I was like “wait a sec, where’s my input?”
I want to know what that is =)
btw, when I ask for examples in React (or any other framework for that matter), I don’t do it in a feisty way, I honestly want to know how others do things so I can compare and maybe copy something. ViewModel is so simple because of that.
I always say that if someone can point to something React/Angular/whatever does in a simpler manner than ViewModel, it won’t be for long because I’ll copy it. I don’t get that very often though, the last one was with elm, which I copied the way it handles event streams like mouse position.
Right now I’m working to bring that simplicity to React. By the time I’m done I hope you’ll be able to write this:
One thing to note is that, while I strongly believe doing more with less ceremonies is important, I think the biggest advantage of using ViewModel is the way components communicate with each other. It makes it super easy for two components to share a small part of their state and also to use child components as controls, among other things. That’s what I want to bring to React.
I thought about this and I’m adding the functionality so it accepts multiple bindings (not just events). The reason is that I can’t predict what custom bindings people are going to be creating or combining. I guess you could say I took the lazy route in the end.
I’m also removing the check to see if the event is supported because it’s not foolproof (as you can see with focusout). It’s a shame because I like the nice message to tell you if you misspelled a binding or event. Can’t win them all.
Hi @manuel, that looks great. I understand VM is on top of Meteor now. Is there any chance to make VM work without Meteor? I ask because I am currently forced to work in an n-tier corporate stack (APIs + Sails JS + React) which is quite remote from embracing Meteor. Just wondering
That’s exactly what I’m working on. A ViewModel that uses React instead of Blaze. It will be separate from Meteor so you’ll be able to use it wherever you use React.