Re: [ClojureScript] Using a state machine to design/program UI ?
2015-06-01 17:35 GMT+02:00 Khalid Jebbari khalid.jebb...@gmail.com: So the various states are encapsulated in a go loop? In multiple go-loops, actually. I always knew that core.async could be used to model FSM's. In a way, core.async go blocks desugar into an fsm implementation (reified state, explicit state transitions). Maybe that's what makes them well-suited to implementing FSMs on top. Well, if you can share the code somehow, do so. https://www.refheap.com/101966 -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] Using a state machine to design/program UI ?
Thx ! Will be an interesting read Le 1 juin 2015 à 18:00, Herwig Hochleitner hhochleit...@gmail.com a écrit : 2015-06-01 17:35 GMT+02:00 Khalid Jebbari khalid.jebb...@gmail.com: So the various states are encapsulated in a go loop? In multiple go-loops, actually. I always knew that core.async could be used to model FSM's. In a way, core.async go blocks desugar into an fsm implementation (reified state, explicit state transitions). Maybe that's what makes them well-suited to implementing FSMs on top. Well, if you can share the code somehow, do so. https://www.refheap.com/101966 -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to a topic in the Google Groups ClojureScript group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojurescript/7STtgK5QiIc/unsubscribe. To unsubscribe from this group and all its topics, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] Using a state machine to design/program UI ?
So the various states are encapsulated in a go loop ? I always knew that core.async could be used to model FSM's. Well, if you can share the code somehow, do so. Le 1 juin 2015 à 15:26, Herwig Hochleitner hhochleit...@gmail.com a écrit : Wow, big thread. I just want to offer, how I've done a FSM implementation in CLJS: - FSM edges are core.async channels - FSM state changes are represented by passing a token object (which can contain additional state vars) across an edge channel - Each state is represented by a go-loop, with a single in-edge and multiple out-edges - After being passed the token by its in-edge, a state runs, then passes the token to one of its out-edges All said and done, this mainly exploits the excellent work on core.async and core.match. Overall, it smells a lot like actors, only that the possible messages are pre-determined. If you are interested, ping me for code. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to a topic in the Google Groups ClojureScript group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojurescript/7STtgK5QiIc/unsubscribe. To unsubscribe from this group and all its topics, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] Using a state machine to design/program UI ?
Wow, big thread. I just want to offer, how I've done a FSM implementation in CLJS: - FSM edges are core.async channels - FSM state changes are represented by passing a token object (which can contain additional state vars) across an edge channel - Each state is represented by a go-loop, with a single in-edge and multiple out-edges - After being passed the token by its in-edge, a state runs, then passes the token to one of its out-edges All said and done, this mainly exploits the excellent work on core.async and core.match. Overall, it smells a lot like actors, only that the possible messages are pre-determined. If you are interested, ping me for code. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] Using a state machine to design/program UI ?
Perhaps of interest: http://www.drdobbs.com/who-moved-my-state/184401643 . Miro Samek's work with statecharts became quite influential in the embedded world. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] Using a state machine to design/program UI ?
I just discovered it! 70 messages in this thread ;) A tcp server (one of the examples) is nothing like the scenarios in the UI but this type of reducing is what i was converging to, not for UI though... Sent from my iPhone On May 22, 2015, at 9:24 AM, Khalid Jebbari khalid.jebb...@gmail.com wrote: I mentioned it in the very first post of this discussion Khalid aka DjebbZ @Dj3bbZ On Fri, May 22, 2015 at 5:57 PM, Marc Fawzi marc.fa...@gmail.com wrote: this looks like fun https://github.com/cdorrat/reduce-fsm ;) On Wed, May 20, 2015 at 7:26 AM, Marc Fawzi marc.fa...@gmail.com wrote: Yup, well captured. On Wed, May 20, 2015 at 6:58 AM, Khalid Jebbari khalid.jebb...@gmail.com wrote: You would want it if you want to inspect/debug/transmit/replay the whole the state of your application. Having nothing encapsulated and everything in a global state permits this. Khalid aka DjebbZ @Dj3bbZ On Wed, May 20, 2015 at 3:51 PM, Jamie Orchard-Hays jamie...@gmail.com wrote: For local state, I mean state that has to do only with the component itself, nothing to do with the data itself. For example, if I have a component that can switch between editing/reading states, I can't imagine why I would want this information stored outside of the component itself. Jamie On May 19, 2015, at 11:58 AM, Daniel Kersten dkers...@gmail.com wrote: I don't think it implies local state, necessarily, although it may benefit from it. I think alternatives can be modular too. For example, re-frame's approach of a central place to store data is like a Blackboard system, which may even help modularity, not hinder it, because modules don't need to know anything about each other - only that the data they read and write is in the central place and may be (transparent to the modules) be accessed/updated by multiple modules transparently (and hopefully gets validated eg through a schema or constraint system to prevent one module from writing data that breaks another module). On the other hand, local state implies encapsulation and encourages strict interfaces to access it, which can also help modularity. In my personal experience this has (more often than not) led to tightly coupled modules instead, however. I personally prefer the re-frame single-place-for-data approach because in my opinion its benefits outweigh its disadvantages, but perhaps I've just been doing local state wrong :) (actually pretty likely!) PS: It'll probably be some time before I get a chance to read Horrocks' book. If anybody knows of any similar content available on the web for me to read in the meantime, I'd love to hear of it! On Tue, 19 May 2015 at 14:34 Jamie Orchard-Hays jamie...@gmail.com wrote: I agree. The word that came to mind while reading your comments, Daniel, was modularity. Does modularity imply local state? Pondering... Jamie On May 18, 2015, at 1:26 PM, Khalid Jebbari khalid.jebb...@gmail.com wrote: I like how you break up the state machines, it has sense in web app. Page 1 has 2 widgets, page 2 has a form. Each widget/form can have a FSM associated with it, the higher level FSM knowing just the higher level state of all widget displayed. Mmmh... Interesting. Le 18 mai 2015 à 19:13, Daniel Kersten dkers...@gmail.com a écrit : From my understanding of it: Use higher level states and decouple them somewhat from the data. For example, games do have lots of dynamically changing data. In a modern shooter you might have dozens of characters with positions, orientation, velocity, health information, weapons, ammunition, etc all of which can be constantly changing. And that's just taking the characters into account. I wouldn't go and build a state machine that enumerates all of the possible transitions from a twelve characters with done distribution of attributes in this location moving in that direction state. I'd break it down so that each character has a high level state like seeking powerup or running. Probably not a great example although it does illustrate that you might have a hierarchy of state machines. In the game example, the highest level might be something like in play or paused and the lowest might be an each characters firing weapon. In client side web app, you could say that each configuration of data is a state (the re-frame readme mentions that you could think of the app-db like this), but I think that's too fine grained to be useful. Instead I'd define higher level states (possibly in a hierarchy). I'd ask myself, regardless of the data available, what are the logical states that a user could be in and for each one, what are the actions that they can perform (and what state does each action transition them to). This could be as simple as pages and links, but with a rich single page application it's more likely finer grained than that. Maybe what dialogs or
Re: [ClojureScript] Using a state machine to design/program UI ?
this looks like fun https://github.com/cdorrat/reduce-fsm ;) On Wed, May 20, 2015 at 7:26 AM, Marc Fawzi marc.fa...@gmail.com wrote: Yup, well captured. On Wed, May 20, 2015 at 6:58 AM, Khalid Jebbari khalid.jebb...@gmail.com wrote: You would want it if you want to inspect/debug/transmit/replay the whole the state of your application. Having nothing encapsulated and everything in a global state permits this. Khalid aka DjebbZ @Dj3bbZ On Wed, May 20, 2015 at 3:51 PM, Jamie Orchard-Hays jamie...@gmail.com wrote: For local state, I mean state that has to do only with the component itself, nothing to do with the data itself. For example, if I have a component that can switch between editing/reading states, I can't imagine why I would want this information stored outside of the component itself. Jamie On May 19, 2015, at 11:58 AM, Daniel Kersten dkers...@gmail.com wrote: I don't think it implies local state, necessarily, although it may benefit from it. I think alternatives can be modular too. For example, re-frame's approach of a central place to store data is like a Blackboard system, which may even help modularity, not hinder it, because modules don't need to know anything about each other - only that the data they read and write is in the central place and may be (transparent to the modules) be accessed/updated by multiple modules transparently (and hopefully gets validated eg through a schema or constraint system to prevent one module from writing data that breaks another module). On the other hand, local state implies encapsulation and encourages strict interfaces to access it, which can also help modularity. In my personal experience this has (more often than not) led to tightly coupled modules instead, however. I personally prefer the re-frame single-place-for-data approach because in my opinion its benefits outweigh its disadvantages, but perhaps I've just been doing local state wrong :) (actually pretty likely!) PS: It'll probably be some time before I get a chance to read Horrocks' book. If anybody knows of any similar content available on the web for me to read in the meantime, I'd love to hear of it! On Tue, 19 May 2015 at 14:34 Jamie Orchard-Hays jamie...@gmail.com wrote: I agree. The word that came to mind while reading your comments, Daniel, was modularity. Does modularity imply local state? Pondering... Jamie On May 18, 2015, at 1:26 PM, Khalid Jebbari khalid.jebb...@gmail.com wrote: I like how you break up the state machines, it has sense in web app. Page 1 has 2 widgets, page 2 has a form. Each widget/form can have a FSM associated with it, the higher level FSM knowing just the higher level state of all widget displayed. Mmmh... Interesting. Le 18 mai 2015 à 19:13, Daniel Kersten dkers...@gmail.com a écrit : From my understanding of it: Use higher level states and decouple them somewhat from the data. For example, games do have lots of dynamically changing data. In a modern shooter you might have dozens of characters with positions, orientation, velocity, health information, weapons, ammunition, etc all of which can be constantly changing. And that's just taking the characters into account. I wouldn't go and build a state machine that enumerates all of the possible transitions from a twelve characters with done distribution of attributes in this location moving in that direction state. I'd break it down so that each character has a high level state like seeking powerup or running. Probably not a great example although it does illustrate that you might have a hierarchy of state machines. In the game example, the highest level might be something like in play or paused and the lowest might be an each characters firing weapon. In client side web app, you could say that each configuration of data is a state (the re-frame readme mentions that you could think of the app-db like this), but I think that's too fine grained to be useful. Instead I'd define higher level states (possibly in a hierarchy). I'd ask myself, regardless of the data available, what are the logical states that a user could be in and for each one, what are the actions that they can perform (and what state does each action transition them to). This could be as simple as pages and links, but with a rich single page application it's more likely finer grained than that. Maybe what dialogs or widgets are accessible. Again, you could then layer these into a hierarchy of state machines. One advantage of this is you always know what a user can do at any given time because you can look at what state they're in. I think of FSM states as orthogonal to the data, not as the data itself. The states dictate what data is accessible and what can be done to it; the data doesn't dictate what state the application is in. I suppose terminology gets confusing, but this is the approach I'm toying with. I'll see how that goes :) But
Re: [ClojureScript] Using a state machine to design/program UI ?
I mentioned it in the very first post of this discussion Khalid aka DjebbZ @Dj3bbZ On Fri, May 22, 2015 at 5:57 PM, Marc Fawzi marc.fa...@gmail.com wrote: this looks like fun https://github.com/cdorrat/reduce-fsm ;) On Wed, May 20, 2015 at 7:26 AM, Marc Fawzi marc.fa...@gmail.com wrote: Yup, well captured. On Wed, May 20, 2015 at 6:58 AM, Khalid Jebbari khalid.jebb...@gmail.com wrote: You would want it if you want to inspect/debug/transmit/replay the whole the state of your application. Having nothing encapsulated and everything in a global state permits this. Khalid aka DjebbZ @Dj3bbZ On Wed, May 20, 2015 at 3:51 PM, Jamie Orchard-Hays jamie...@gmail.com wrote: For local state, I mean state that has to do only with the component itself, nothing to do with the data itself. For example, if I have a component that can switch between editing/reading states, I can't imagine why I would want this information stored outside of the component itself. Jamie On May 19, 2015, at 11:58 AM, Daniel Kersten dkers...@gmail.com wrote: I don't think it implies local state, necessarily, although it may benefit from it. I think alternatives can be modular too. For example, re-frame's approach of a central place to store data is like a Blackboard system, which may even help modularity, not hinder it, because modules don't need to know anything about each other - only that the data they read and write is in the central place and may be (transparent to the modules) be accessed/updated by multiple modules transparently (and hopefully gets validated eg through a schema or constraint system to prevent one module from writing data that breaks another module). On the other hand, local state implies encapsulation and encourages strict interfaces to access it, which can also help modularity. In my personal experience this has (more often than not) led to tightly coupled modules instead, however. I personally prefer the re-frame single-place-for-data approach because in my opinion its benefits outweigh its disadvantages, but perhaps I've just been doing local state wrong :) (actually pretty likely!) PS: It'll probably be some time before I get a chance to read Horrocks' book. If anybody knows of any similar content available on the web for me to read in the meantime, I'd love to hear of it! On Tue, 19 May 2015 at 14:34 Jamie Orchard-Hays jamie...@gmail.com wrote: I agree. The word that came to mind while reading your comments, Daniel, was modularity. Does modularity imply local state? Pondering... Jamie On May 18, 2015, at 1:26 PM, Khalid Jebbari khalid.jebb...@gmail.com wrote: I like how you break up the state machines, it has sense in web app. Page 1 has 2 widgets, page 2 has a form. Each widget/form can have a FSM associated with it, the higher level FSM knowing just the higher level state of all widget displayed. Mmmh... Interesting. Le 18 mai 2015 à 19:13, Daniel Kersten dkers...@gmail.com a écrit : From my understanding of it: Use higher level states and decouple them somewhat from the data. For example, games do have lots of dynamically changing data. In a modern shooter you might have dozens of characters with positions, orientation, velocity, health information, weapons, ammunition, etc all of which can be constantly changing. And that's just taking the characters into account. I wouldn't go and build a state machine that enumerates all of the possible transitions from a twelve characters with done distribution of attributes in this location moving in that direction state. I'd break it down so that each character has a high level state like seeking powerup or running. Probably not a great example although it does illustrate that you might have a hierarchy of state machines. In the game example, the highest level might be something like in play or paused and the lowest might be an each characters firing weapon. In client side web app, you could say that each configuration of data is a state (the re-frame readme mentions that you could think of the app-db like this), but I think that's too fine grained to be useful. Instead I'd define higher level states (possibly in a hierarchy). I'd ask myself, regardless of the data available, what are the logical states that a user could be in and for each one, what are the actions that they can perform (and what state does each action transition them to). This could be as simple as pages and links, but with a rich single page application it's more likely finer grained than that. Maybe what dialogs or widgets are accessible. Again, you could then layer these into a hierarchy of state machines. One advantage of this is you always know what a user can do at any given time because you can look at what state they're in. I think of FSM states as orthogonal to the data, not as the data itself. The states dictate what data is accessible and what can be done to it; the data
Re: [ClojureScript] Using a state machine to design/program UI ?
For local state, I mean state that has to do only with the component itself, nothing to do with the data itself. For example, if I have a component that can switch between editing/reading states, I can't imagine why I would want this information stored outside of the component itself. Jamie On May 19, 2015, at 11:58 AM, Daniel Kersten dkers...@gmail.com wrote: I don't think it implies local state, necessarily, although it may benefit from it. I think alternatives can be modular too. For example, re-frame's approach of a central place to store data is like a Blackboard system, which may even help modularity, not hinder it, because modules don't need to know anything about each other - only that the data they read and write is in the central place and may be (transparent to the modules) be accessed/updated by multiple modules transparently (and hopefully gets validated eg through a schema or constraint system to prevent one module from writing data that breaks another module). On the other hand, local state implies encapsulation and encourages strict interfaces to access it, which can also help modularity. In my personal experience this has (more often than not) led to tightly coupled modules instead, however. I personally prefer the re-frame single-place-for-data approach because in my opinion its benefits outweigh its disadvantages, but perhaps I've just been doing local state wrong :) (actually pretty likely!) PS: It'll probably be some time before I get a chance to read Horrocks' book. If anybody knows of any similar content available on the web for me to read in the meantime, I'd love to hear of it! On Tue, 19 May 2015 at 14:34 Jamie Orchard-Hays jamie...@gmail.com wrote: I agree. The word that came to mind while reading your comments, Daniel, was modularity. Does modularity imply local state? Pondering... Jamie On May 18, 2015, at 1:26 PM, Khalid Jebbari khalid.jebb...@gmail.com wrote: I like how you break up the state machines, it has sense in web app. Page 1 has 2 widgets, page 2 has a form. Each widget/form can have a FSM associated with it, the higher level FSM knowing just the higher level state of all widget displayed. Mmmh... Interesting. Le 18 mai 2015 à 19:13, Daniel Kersten dkers...@gmail.com a écrit : From my understanding of it: Use higher level states and decouple them somewhat from the data. For example, games do have lots of dynamically changing data. In a modern shooter you might have dozens of characters with positions, orientation, velocity, health information, weapons, ammunition, etc all of which can be constantly changing. And that's just taking the characters into account. I wouldn't go and build a state machine that enumerates all of the possible transitions from a twelve characters with done distribution of attributes in this location moving in that direction state. I'd break it down so that each character has a high level state like seeking powerup or running. Probably not a great example although it does illustrate that you might have a hierarchy of state machines. In the game example, the highest level might be something like in play or paused and the lowest might be an each characters firing weapon. In client side web app, you could say that each configuration of data is a state (the re-frame readme mentions that you could think of the app-db like this), but I think that's too fine grained to be useful. Instead I'd define higher level states (possibly in a hierarchy). I'd ask myself, regardless of the data available, what are the logical states that a user could be in and for each one, what are the actions that they can perform (and what state does each action transition them to). This could be as simple as pages and links, but with a rich single page application it's more likely finer grained than that. Maybe what dialogs or widgets are accessible. Again, you could then layer these into a hierarchy of state machines. One advantage of this is you always know what a user can do at any given time because you can look at what state they're in. I think of FSM states as orthogonal to the data, not as the data itself. The states dictate what data is accessible and what can be done to it; the data doesn't dictate what state the application is in. I suppose terminology gets confusing, but this is the approach I'm toying with. I'll see how that goes :) But yeah, needs more thinking. On Mon, 18 May 2015 16:55 Marc Fawzi marc.fa...@gmail.com wrote: Games are ideal candidate for straight-forward FSM implementation since you normally download the data at game load time and from there on you have a *relatively* small set of states that can be transitioned between based in user input. You can even apply state minimization techniques to reduce the total number of states. But in a web app you are continuously grabbing
Re: [ClojureScript] Using a state machine to design/program UI ?
You would want it if you want to inspect/debug/transmit/replay the whole the state of your application. Having nothing encapsulated and everything in a global state permits this. Khalid aka DjebbZ @Dj3bbZ On Wed, May 20, 2015 at 3:51 PM, Jamie Orchard-Hays jamie...@gmail.com wrote: For local state, I mean state that has to do only with the component itself, nothing to do with the data itself. For example, if I have a component that can switch between editing/reading states, I can't imagine why I would want this information stored outside of the component itself. Jamie On May 19, 2015, at 11:58 AM, Daniel Kersten dkers...@gmail.com wrote: I don't think it implies local state, necessarily, although it may benefit from it. I think alternatives can be modular too. For example, re-frame's approach of a central place to store data is like a Blackboard system, which may even help modularity, not hinder it, because modules don't need to know anything about each other - only that the data they read and write is in the central place and may be (transparent to the modules) be accessed/updated by multiple modules transparently (and hopefully gets validated eg through a schema or constraint system to prevent one module from writing data that breaks another module). On the other hand, local state implies encapsulation and encourages strict interfaces to access it, which can also help modularity. In my personal experience this has (more often than not) led to tightly coupled modules instead, however. I personally prefer the re-frame single-place-for-data approach because in my opinion its benefits outweigh its disadvantages, but perhaps I've just been doing local state wrong :) (actually pretty likely!) PS: It'll probably be some time before I get a chance to read Horrocks' book. If anybody knows of any similar content available on the web for me to read in the meantime, I'd love to hear of it! On Tue, 19 May 2015 at 14:34 Jamie Orchard-Hays jamie...@gmail.com wrote: I agree. The word that came to mind while reading your comments, Daniel, was modularity. Does modularity imply local state? Pondering... Jamie On May 18, 2015, at 1:26 PM, Khalid Jebbari khalid.jebb...@gmail.com wrote: I like how you break up the state machines, it has sense in web app. Page 1 has 2 widgets, page 2 has a form. Each widget/form can have a FSM associated with it, the higher level FSM knowing just the higher level state of all widget displayed. Mmmh... Interesting. Le 18 mai 2015 à 19:13, Daniel Kersten dkers...@gmail.com a écrit : From my understanding of it: Use higher level states and decouple them somewhat from the data. For example, games do have lots of dynamically changing data. In a modern shooter you might have dozens of characters with positions, orientation, velocity, health information, weapons, ammunition, etc all of which can be constantly changing. And that's just taking the characters into account. I wouldn't go and build a state machine that enumerates all of the possible transitions from a twelve characters with done distribution of attributes in this location moving in that direction state. I'd break it down so that each character has a high level state like seeking powerup or running. Probably not a great example although it does illustrate that you might have a hierarchy of state machines. In the game example, the highest level might be something like in play or paused and the lowest might be an each characters firing weapon. In client side web app, you could say that each configuration of data is a state (the re-frame readme mentions that you could think of the app-db like this), but I think that's too fine grained to be useful. Instead I'd define higher level states (possibly in a hierarchy). I'd ask myself, regardless of the data available, what are the logical states that a user could be in and for each one, what are the actions that they can perform (and what state does each action transition them to). This could be as simple as pages and links, but with a rich single page application it's more likely finer grained than that. Maybe what dialogs or widgets are accessible. Again, you could then layer these into a hierarchy of state machines. One advantage of this is you always know what a user can do at any given time because you can look at what state they're in. I think of FSM states as orthogonal to the data, not as the data itself. The states dictate what data is accessible and what can be done to it; the data doesn't dictate what state the application is in. I suppose terminology gets confusing, but this is the approach I'm toying with. I'll see how that goes :) But yeah, needs more thinking. On Mon, 18 May 2015 16:55 Marc Fawzi marc.fa...@gmail.com wrote: Games are ideal candidate for straight-forward FSM implementation since you normally download the data at game load time and from there on you have a
Re: [ClojureScript] Using a state machine to design/program UI ?
Thanks, Khalid. Jamie On May 20, 2015, at 9:58 AM, Khalid Jebbari khalid.jebb...@gmail.com wrote: You would want it if you want to inspect/debug/transmit/replay the whole the state of your application. Having nothing encapsulated and everything in a global state permits this. Khalid aka DjebbZ @Dj3bbZ On Wed, May 20, 2015 at 3:51 PM, Jamie Orchard-Hays jamie...@gmail.com wrote: For local state, I mean state that has to do only with the component itself, nothing to do with the data itself. For example, if I have a component that can switch between editing/reading states, I can't imagine why I would want this information stored outside of the component itself. Jamie On May 19, 2015, at 11:58 AM, Daniel Kersten dkers...@gmail.com wrote: I don't think it implies local state, necessarily, although it may benefit from it. I think alternatives can be modular too. For example, re-frame's approach of a central place to store data is like a Blackboard system, which may even help modularity, not hinder it, because modules don't need to know anything about each other - only that the data they read and write is in the central place and may be (transparent to the modules) be accessed/updated by multiple modules transparently (and hopefully gets validated eg through a schema or constraint system to prevent one module from writing data that breaks another module). On the other hand, local state implies encapsulation and encourages strict interfaces to access it, which can also help modularity. In my personal experience this has (more often than not) led to tightly coupled modules instead, however. I personally prefer the re-frame single-place-for-data approach because in my opinion its benefits outweigh its disadvantages, but perhaps I've just been doing local state wrong :) (actually pretty likely!) PS: It'll probably be some time before I get a chance to read Horrocks' book. If anybody knows of any similar content available on the web for me to read in the meantime, I'd love to hear of it! On Tue, 19 May 2015 at 14:34 Jamie Orchard-Hays jamie...@gmail.com wrote: I agree. The word that came to mind while reading your comments, Daniel, was modularity. Does modularity imply local state? Pondering... Jamie On May 18, 2015, at 1:26 PM, Khalid Jebbari khalid.jebb...@gmail.com wrote: I like how you break up the state machines, it has sense in web app. Page 1 has 2 widgets, page 2 has a form. Each widget/form can have a FSM associated with it, the higher level FSM knowing just the higher level state of all widget displayed. Mmmh... Interesting. Le 18 mai 2015 à 19:13, Daniel Kersten dkers...@gmail.com a écrit : From my understanding of it: Use higher level states and decouple them somewhat from the data. For example, games do have lots of dynamically changing data. In a modern shooter you might have dozens of characters with positions, orientation, velocity, health information, weapons, ammunition, etc all of which can be constantly changing. And that's just taking the characters into account. I wouldn't go and build a state machine that enumerates all of the possible transitions from a twelve characters with done distribution of attributes in this location moving in that direction state. I'd break it down so that each character has a high level state like seeking powerup or running. Probably not a great example although it does illustrate that you might have a hierarchy of state machines. In the game example, the highest level might be something like in play or paused and the lowest might be an each characters firing weapon. In client side web app, you could say that each configuration of data is a state (the re-frame readme mentions that you could think of the app-db like this), but I think that's too fine grained to be useful. Instead I'd define higher level states (possibly in a hierarchy). I'd ask myself, regardless of the data available, what are the logical states that a user could be in and for each one, what are the actions that they can perform (and what state does each action transition them to). This could be as simple as pages and links, but with a rich single page application it's more likely finer grained than that. Maybe what dialogs or widgets are accessible. Again, you could then layer these into a hierarchy of state machines. One advantage of this is you always know what a user can do at any given time because you can look at what state they're in. I think of FSM states as orthogonal to the data, not as the data itself. The states dictate what data is accessible and what can be done to it; the data doesn't dictate what state the application is in. I suppose terminology gets confusing, but this is the approach I'm toying with. I'll see how that goes :) But yeah, needs more thinking. On Mon, 18 May 2015 16:55 Marc Fawzi
Re: [ClojureScript] Using a state machine to design/program UI ?
Yup, well captured. On Wed, May 20, 2015 at 6:58 AM, Khalid Jebbari khalid.jebb...@gmail.com wrote: You would want it if you want to inspect/debug/transmit/replay the whole the state of your application. Having nothing encapsulated and everything in a global state permits this. Khalid aka DjebbZ @Dj3bbZ On Wed, May 20, 2015 at 3:51 PM, Jamie Orchard-Hays jamie...@gmail.com wrote: For local state, I mean state that has to do only with the component itself, nothing to do with the data itself. For example, if I have a component that can switch between editing/reading states, I can't imagine why I would want this information stored outside of the component itself. Jamie On May 19, 2015, at 11:58 AM, Daniel Kersten dkers...@gmail.com wrote: I don't think it implies local state, necessarily, although it may benefit from it. I think alternatives can be modular too. For example, re-frame's approach of a central place to store data is like a Blackboard system, which may even help modularity, not hinder it, because modules don't need to know anything about each other - only that the data they read and write is in the central place and may be (transparent to the modules) be accessed/updated by multiple modules transparently (and hopefully gets validated eg through a schema or constraint system to prevent one module from writing data that breaks another module). On the other hand, local state implies encapsulation and encourages strict interfaces to access it, which can also help modularity. In my personal experience this has (more often than not) led to tightly coupled modules instead, however. I personally prefer the re-frame single-place-for-data approach because in my opinion its benefits outweigh its disadvantages, but perhaps I've just been doing local state wrong :) (actually pretty likely!) PS: It'll probably be some time before I get a chance to read Horrocks' book. If anybody knows of any similar content available on the web for me to read in the meantime, I'd love to hear of it! On Tue, 19 May 2015 at 14:34 Jamie Orchard-Hays jamie...@gmail.com wrote: I agree. The word that came to mind while reading your comments, Daniel, was modularity. Does modularity imply local state? Pondering... Jamie On May 18, 2015, at 1:26 PM, Khalid Jebbari khalid.jebb...@gmail.com wrote: I like how you break up the state machines, it has sense in web app. Page 1 has 2 widgets, page 2 has a form. Each widget/form can have a FSM associated with it, the higher level FSM knowing just the higher level state of all widget displayed. Mmmh... Interesting. Le 18 mai 2015 à 19:13, Daniel Kersten dkers...@gmail.com a écrit : From my understanding of it: Use higher level states and decouple them somewhat from the data. For example, games do have lots of dynamically changing data. In a modern shooter you might have dozens of characters with positions, orientation, velocity, health information, weapons, ammunition, etc all of which can be constantly changing. And that's just taking the characters into account. I wouldn't go and build a state machine that enumerates all of the possible transitions from a twelve characters with done distribution of attributes in this location moving in that direction state. I'd break it down so that each character has a high level state like seeking powerup or running. Probably not a great example although it does illustrate that you might have a hierarchy of state machines. In the game example, the highest level might be something like in play or paused and the lowest might be an each characters firing weapon. In client side web app, you could say that each configuration of data is a state (the re-frame readme mentions that you could think of the app-db like this), but I think that's too fine grained to be useful. Instead I'd define higher level states (possibly in a hierarchy). I'd ask myself, regardless of the data available, what are the logical states that a user could be in and for each one, what are the actions that they can perform (and what state does each action transition them to). This could be as simple as pages and links, but with a rich single page application it's more likely finer grained than that. Maybe what dialogs or widgets are accessible. Again, you could then layer these into a hierarchy of state machines. One advantage of this is you always know what a user can do at any given time because you can look at what state they're in. I think of FSM states as orthogonal to the data, not as the data itself. The states dictate what data is accessible and what can be done to it; the data doesn't dictate what state the application is in. I suppose terminology gets confusing, but this is the approach I'm toying with. I'll see how that goes :) But yeah, needs more thinking. On Mon, 18 May 2015 16:55 Marc Fawzi marc.fa...@gmail.com wrote: Games are ideal candidate for straight-forward
Re: [ClojureScript] Using a state machine to design/program UI ?
I agree. The word that came to mind while reading your comments, Daniel, was modularity. Does modularity imply local state? Pondering... Jamie On May 18, 2015, at 1:26 PM, Khalid Jebbari khalid.jebb...@gmail.com wrote: I like how you break up the state machines, it has sense in web app. Page 1 has 2 widgets, page 2 has a form. Each widget/form can have a FSM associated with it, the higher level FSM knowing just the higher level state of all widget displayed. Mmmh... Interesting. Le 18 mai 2015 à 19:13, Daniel Kersten dkers...@gmail.com a écrit : From my understanding of it: Use higher level states and decouple them somewhat from the data. For example, games do have lots of dynamically changing data. In a modern shooter you might have dozens of characters with positions, orientation, velocity, health information, weapons, ammunition, etc all of which can be constantly changing. And that's just taking the characters into account. I wouldn't go and build a state machine that enumerates all of the possible transitions from a twelve characters with done distribution of attributes in this location moving in that direction state. I'd break it down so that each character has a high level state like seeking powerup or running. Probably not a great example although it does illustrate that you might have a hierarchy of state machines. In the game example, the highest level might be something like in play or paused and the lowest might be an each characters firing weapon. In client side web app, you could say that each configuration of data is a state (the re-frame readme mentions that you could think of the app-db like this), but I think that's too fine grained to be useful. Instead I'd define higher level states (possibly in a hierarchy). I'd ask myself, regardless of the data available, what are the logical states that a user could be in and for each one, what are the actions that they can perform (and what state does each action transition them to). This could be as simple as pages and links, but with a rich single page application it's more likely finer grained than that. Maybe what dialogs or widgets are accessible. Again, you could then layer these into a hierarchy of state machines. One advantage of this is you always know what a user can do at any given time because you can look at what state they're in. I think of FSM states as orthogonal to the data, not as the data itself. The states dictate what data is accessible and what can be done to it; the data doesn't dictate what state the application is in. I suppose terminology gets confusing, but this is the approach I'm toying with. I'll see how that goes :) But yeah, needs more thinking. On Mon, 18 May 2015 16:55 Marc Fawzi marc.fa...@gmail.com wrote: Games are ideal candidate for straight-forward FSM implementation since you normally download the data at game load time and from there on you have a *relatively* small set of states that can be transitioned between based in user input. You can even apply state minimization techniques to reduce the total number of states. But in a web app you are continuously grabbing data from the server and that data is generated based on not only user input but also the state of the server side database and that server generated data would modify UI side app state and you have to account for all possibilities so the total number of states could grow wildly if your UI is data driven (where the state of the UI depends on the data in non-trivial ways) but even if your UI state dependence on server data was a trivial relationship you could still end up with a huge state diagram for the simplest viable business app if you include templating the view as part of the UI FSM on top of business logic. You could segment your app into micro apps and that will help regardless of whether you're building the app as FSM or not. And what if the state transitions are probability driven? How many states will you end up having to chart? Not convinced YET... Sent from my iPhone On May 18, 2015, at 6:57 AM, Sean Tempesta sean.tempe...@gmail.com wrote: Hi Khalid. I found your topic interesting so I thought I'd chime in. Regarding your comments on routing: So, under normal conditions, the initial URL sets the FSM in motion (as an event). We could call this entry point a routing state. Afterward, the state transitions are controlling the urls (not the other way around), right? Outside of normal conditions (ie. people copying and pasting links into random parts of the system), you also just send the url to the routing state and then switch to a new state based on whatever rules and definitions you've set. Or maybe I'm missing something. I haven't built an FSM in a while. :) Sean On Monday, May 18, 2015 at 6:07:22 PM UTC+8, Khalid Jebbari wrote: Trying to
Re: [ClojureScript] Using a state machine to design/program UI ?
I don't think it implies local state, necessarily, although it may benefit from it. I think alternatives can be modular too. For example, re-frame's approach of a central place to store data is like a Blackboard system, which may even help modularity, not hinder it, because modules don't need to know anything about each other - only that the data they read and write is in the central place and may be (transparent to the modules) be accessed/updated by multiple modules transparently (and hopefully gets validated eg through a schema or constraint system to prevent one module from writing data that breaks another module). On the other hand, local state implies encapsulation and encourages strict interfaces to access it, which can also help modularity. In my personal experience this has (more often than not) led to tightly coupled modules instead, however. I personally prefer the re-frame single-place-for-data approach because in my opinion its benefits outweigh its disadvantages, but perhaps I've just been doing local state wrong :) (actually pretty likely!) PS: It'll probably be some time before I get a chance to read Horrocks' book. If anybody knows of any similar content available on the web for me to read in the meantime, I'd love to hear of it! On Tue, 19 May 2015 at 14:34 Jamie Orchard-Hays jamie...@gmail.com wrote: I agree. The word that came to mind while reading your comments, Daniel, was modularity. Does modularity imply local state? Pondering... Jamie On May 18, 2015, at 1:26 PM, Khalid Jebbari khalid.jebb...@gmail.com wrote: I like how you break up the state machines, it has sense in web app. Page 1 has 2 widgets, page 2 has a form. Each widget/form can have a FSM associated with it, the higher level FSM knowing just the higher level state of all widget displayed. Mmmh... Interesting. Le 18 mai 2015 à 19:13, Daniel Kersten dkers...@gmail.com a écrit : From my understanding of it: Use higher level states and decouple them somewhat from the data. For example, games do have lots of dynamically changing data. In a modern shooter you might have dozens of characters with positions, orientation, velocity, health information, weapons, ammunition, etc all of which can be constantly changing. And that's just taking the characters into account. I wouldn't go and build a state machine that enumerates all of the possible transitions from a twelve characters with done distribution of attributes in this location moving in that direction state. I'd break it down so that each character has a high level state like seeking powerup or running. Probably not a great example although it does illustrate that you might have a hierarchy of state machines. In the game example, the highest level might be something like in play or paused and the lowest might be an each characters firing weapon. In client side web app, you could say that each configuration of data is a state (the re-frame readme mentions that you could think of the app-db like this), but I think that's too fine grained to be useful. Instead I'd define higher level states (possibly in a hierarchy). I'd ask myself, regardless of the data available, what are the logical states that a user could be in and for each one, what are the actions that they can perform (and what state does each action transition them to). This could be as simple as pages and links, but with a rich single page application it's more likely finer grained than that. Maybe what dialogs or widgets are accessible. Again, you could then layer these into a hierarchy of state machines. One advantage of this is you always know what a user can do at any given time because you can look at what state they're in. I think of FSM states as orthogonal to the data, not as the data itself. The states dictate what data is accessible and what can be done to it; the data doesn't dictate what state the application is in. I suppose terminology gets confusing, but this is the approach I'm toying with. I'll see how that goes :) But yeah, needs more thinking. On Mon, 18 May 2015 16:55 Marc Fawzi marc.fa...@gmail.com wrote: Games are ideal candidate for straight-forward FSM implementation since you normally download the data at game load time and from there on you have a *relatively* small set of states that can be transitioned between based in user input. You can even apply state minimization techniques to reduce the total number of states. But in a web app you are continuously grabbing data from the server and that data is generated based on not only user input but also the state of the server side database and that server generated data would modify UI side app state and you have to account for all possibilities so the total number of states could grow wildly if your UI is data driven (where the state of the UI depends on the data in non-trivial ways) but even if your UI state dependence on server data was a trivial relationship
Re: [ClojureScript] Using a state machine to design/program UI ?
Here's where I find local state useful and I am curious how advocates of centralized state handle it: A view component that allows editing. For example, click on the text and it changes to an input element. To me that is local state: I'm in reading mode. Now I'm in editing mode. In my own app, I don't allow other components to change to editing mode when any other is in editing mode. This is a global state. So there is coordination, but it's not terrible as the component sets its local state and dispatches the handler for the app state at the same time. How do you all do it? Jamie On May 15, 2015, at 1:08 AM, Mike Thompson m.l.thompson...@gmail.com wrote: On Friday, May 15, 2015 at 10:27:46 AM UTC+10, Daniel Kersten wrote: Personally I find that moving state out of components as re-frame's subscriptions and handlers encourage is a desirable trait and would be cautious about reintroducing local state. Keeping my data in one place (and handling updates and queries through a centralised place) has made it a lot easier for me to manage complex data and logic. I've played with javelin in the past and it's a fantastic library. I quite like the idea of using it as a replacement for (or perhaps together with?) re-frames subscriptions (so reagents ratoms, really), but in my opinion reliance on local state is a mistake. I'd like to violently agree with you. :-) State in the one place simplifies so much. The moment you have state in multiple places, and that state needs synchronization, you have a problem. The strategy for solving that problem will involve either (1) things watching other things for changes or (2) things telling other things they have changed. The OO paradigm encourages a lot of distributed, synchronized state, and the The Observer pattern is used to handle it. Those that use component local state with OM, have the same issues as the OO paradigm. Sometimes they use a global bus to achieve synconization (things telling other things that something has changed) which is a similar pattern to various OO framemworks, like PureMVC. In the functional programming space, the movement seems to be towards FRP. Data flows into functions and out again, in something of a pipeline. The structure of those flows is more declarative WRT time. The thing is this: synchronization of state is a pain. Have as little of it going on as you can. Putting all your data in the one place certainly saves you from a certain class of problem -- reintroducing distributed state WILL cause you some grief. I'm not saying never do it, but I am saying there'd want to be a big payoff to warrant the pain. -- Mike -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] Using a state machine to design/program UI ?
I would assume you're right that very few are transient. At least with Mikes approach, you can log the error, notify the user and continue working from a clean state (but I assume if the user does the same thing again the error would happen again - that is, they can continue doing other things). On Fri, 15 May 2015 16:03 Colin Yates colin.ya...@gmail.com wrote: Data for the win. I remember in the olden days when AOP reared its head and people were talking about retrying updates against stale data/exceptions. I was always/still am a bit cynical because I just don't see that many exceptions where the exception is transient and the second attempt would work. I would be very interested to know how many UHEs are genuinely 'transient', in that they don't happen again when the user tries to do the same thing - do you have any metrics? On 15 May 2015 at 15:56, Mike Thompson m.l.thompson...@gmail.com wrote: On Saturday, May 16, 2015 at 12:36:02 AM UTC+10, Colin Yates wrote: For me, I can't use the 'snapshot app-db and discard' as the app-db is synchronised with the server periodically. As you mention, I have a number of roots in my app, one for 'ui' entries and one for 'views' which are populated by the server, even if I want to discard the 'ui' root I really don't want to discard the 'views'. I avoid local state as well simply because the benefit of being able to capture the whole app-db and attach it to a bug report is awesome. We've now hooked window.onerror and in production, and when there's an unhandled exception, we automatically do an undo, to take the user back to the previous known sane state. It works a treat. (Not that we get many UHE, you understand :-)) It means the user still has a working program (with error message), and hasn't lost anything because of the problem. AND, as you say, we serialise the app-db and the event which caused the UHE, to form the perfect, reproducible bug report. (We also have a log of all previous events too ... because they are pure data). It brings a tear to my eye its so damn beautiful. That all comes almost for free because the data is all in the one place and because events are pure data to boot. -- Mike -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] Using a state machine to design/program UI ?
On Saturday, May 16, 2015 at 1:03:49 AM UTC+10, Colin Yates wrote: Data for the win. I remember in the olden days when AOP reared its head and people were talking about retrying updates against stale data/exceptions. I was always/still am a bit cynical because I just don't see that many exceptions where the exception is transient and the second attempt would work. I would be very interested to know how many UHEs are genuinely 'transient', in that they don't happen again when the user tries to do the same thing - do you have any metrics? None of ours have been transient (small sample size). But that's because our apps are quite self contained and don't do a lot of chatting with outside servers. Ie. their state is fairly self contained. -- Mike -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] Using a state machine to design/program UI ?
For me, I can't use the 'snapshot app-db and discard' as the app-db is synchronised with the server periodically. As you mention, I have a number of roots in my app, one for 'ui' entries and one for 'views' which are populated by the server, even if I want to discard the 'ui' root I really don't want to discard the 'views'. I avoid local state as well simply because the benefit of being able to capture the whole app-db and attach it to a bug report is awesome. On 15 May 2015 at 15:31, Daniel Kersten dkers...@gmail.com wrote: Am I correct that what you want is a temporary scratchpad where you make edits which can then be committed to the global state, or discarded, based on user action? There are two ways that I've used to do this: The first is to take a snapshot of the state before making changes (perhaps using something like re-frame's undo feature). This way, the application can react to the changes immediately and you don't need any special logic to pull/push data from/to global state and components can read data as they normally would and updates can be made through handlers same as everywhere else. To commit, you don't need to do anything[1], to revert, you throw away the changes by reverting back to the before edit snapshot. The second technique I've used is to store the edit mode data elsewhere in your global data (I've got a :scratchpad key in my app-db for things like this, and other things like what item in a list is selected). You would have to copy data to/from this the same way as with global state, so you don't win anything in the keeping data synchronised department, but the benefit over local state is that your components are dumb[2], your update logic happens in one place and in a consistent way[3] and edits can take part in whatever dataflow logic is applied to global state (eg re-frame's undo; other components can subscribe to it etc). Now, with that said, there are times when there's no way around using local state, in which case I DO use it. But I treat this is a technical detail (either a performance optimisation or to get around the React controlled input glitch where cursor position is lost if updating an inputs value async). This is how I handle it anyway. I do agree that the coordination isn't a big deal in this case and perhaps something like Javelin would actually make it a non issue, but I do feel that there are significant advantages to keeping data global and isolated from view logic and update logic. [1] Realistically, you probably still trigger a commit event to sync with the server or clear the is editing flag and throw away the snapshot. [2] Dumb components are less coupled, easier to understand, easier to test. [3] This makes it easier (for me at least) to understand my code/data, makes it easier to debug and easier to test. It also makes it easier to build development tools (for example, I've got a (currently unreleased) app-db viewer and handler event logger - if I store data locally, then updates are invisible to these tools). On Fri, 15 May 2015 at 13:57 Jamie Orchard-Hays jamie...@gmail.com wrote: Here's where I find local state useful and I am curious how advocates of centralized state handle it: A view component that allows editing. For example, click on the text and it changes to an input element. To me that is local state: I'm in reading mode. Now I'm in editing mode. In my own app, I don't allow other components to change to editing mode when any other is in editing mode. This is a global state. So there is coordination, but it's not terrible as the component sets its local state and dispatches the handler for the app state at the same time. How do you all do it? Jamie On May 15, 2015, at 1:08 AM, Mike Thompson m.l.thompson...@gmail.com wrote: On Friday, May 15, 2015 at 10:27:46 AM UTC+10, Daniel Kersten wrote: Personally I find that moving state out of components as re-frame's subscriptions and handlers encourage is a desirable trait and would be cautious about reintroducing local state. Keeping my data in one place (and handling updates and queries through a centralised place) has made it a lot easier for me to manage complex data and logic. I've played with javelin in the past and it's a fantastic library. I quite like the idea of using it as a replacement for (or perhaps together with?) re-frames subscriptions (so reagents ratoms, really), but in my opinion reliance on local state is a mistake. I'd like to violently agree with you. :-) State in the one place simplifies so much. The moment you have state in multiple places, and that state needs synchronization, you have a problem. The strategy for solving that problem will involve either (1) things watching other things for changes or (2) things telling other things they have changed. The OO paradigm encourages a lot of distributed, synchronized state, and the The Observer pattern
Re: [ClojureScript] Using a state machine to design/program UI ?
On Saturday, May 16, 2015 at 12:36:02 AM UTC+10, Colin Yates wrote: For me, I can't use the 'snapshot app-db and discard' as the app-db is synchronised with the server periodically. As you mention, I have a number of roots in my app, one for 'ui' entries and one for 'views' which are populated by the server, even if I want to discard the 'ui' root I really don't want to discard the 'views'. I avoid local state as well simply because the benefit of being able to capture the whole app-db and attach it to a bug report is awesome. We've now hooked window.onerror and in production, and when there's an unhandled exception, we automatically do an undo, to take the user back to the previous known sane state. It works a treat. (Not that we get many UHE, you understand :-)) It means the user still has a working program (with error message), and hasn't lost anything because of the problem. AND, as you say, we serialise the app-db and the event which caused the UHE, to form the perfect, reproducible bug report. (We also have a log of all previous events too ... because they are pure data). It brings a tear to my eye its so damn beautiful. That all comes almost for free because the data is all in the one place and because events are pure data to boot. -- Mike -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] Using a state machine to design/program UI ?
Am I correct that what you want is a temporary scratchpad where you make edits which can then be committed to the global state, or discarded, based on user action? There are two ways that I've used to do this: The first is to take a snapshot of the state before making changes (perhaps using something like re-frame's undo feature). This way, the application can react to the changes immediately and you don't need any special logic to pull/push data from/to global state and components can read data as they normally would and updates can be made through handlers same as everywhere else. To commit, you don't need to do anything[1], to revert, you throw away the changes by reverting back to the before edit snapshot. The second technique I've used is to store the edit mode data elsewhere in your global data (I've got a :scratchpad key in my app-db for things like this, and other things like what item in a list is selected). You would have to copy data to/from this the same way as with global state, so you don't win anything in the keeping data synchronised department, but the benefit over local state is that your components are dumb[2], your update logic happens in one place and in a consistent way[3] and edits can take part in whatever dataflow logic is applied to global state (eg re-frame's undo; other components can subscribe to it etc). Now, with that said, there are times when there's no way around using local state, in which case I DO use it. But I treat this is a technical detail (either a performance optimisation or to get around the React controlled input glitch where cursor position is lost if updating an inputs value async). This is how I handle it anyway. I do agree that the coordination isn't a big deal in this case and perhaps something like Javelin would actually make it a non issue, but I do feel that there are significant advantages to keeping data global and isolated from view logic and update logic. [1] Realistically, you probably still trigger a commit event to sync with the server or clear the is editing flag and throw away the snapshot. [2] Dumb components are less coupled, easier to understand, easier to test. [3] This makes it easier (for me at least) to understand my code/data, makes it easier to debug and easier to test. It also makes it easier to build development tools (for example, I've got a (currently unreleased) app-db viewer and handler event logger - if I store data locally, then updates are invisible to these tools). On Fri, 15 May 2015 at 13:57 Jamie Orchard-Hays jamie...@gmail.com wrote: Here's where I find local state useful and I am curious how advocates of centralized state handle it: A view component that allows editing. For example, click on the text and it changes to an input element. To me that is local state: I'm in reading mode. Now I'm in editing mode. In my own app, I don't allow other components to change to editing mode when any other is in editing mode. This is a global state. So there is coordination, but it's not terrible as the component sets its local state and dispatches the handler for the app state at the same time. How do you all do it? Jamie On May 15, 2015, at 1:08 AM, Mike Thompson m.l.thompson...@gmail.com wrote: On Friday, May 15, 2015 at 10:27:46 AM UTC+10, Daniel Kersten wrote: Personally I find that moving state out of components as re-frame's subscriptions and handlers encourage is a desirable trait and would be cautious about reintroducing local state. Keeping my data in one place (and handling updates and queries through a centralised place) has made it a lot easier for me to manage complex data and logic. I've played with javelin in the past and it's a fantastic library. I quite like the idea of using it as a replacement for (or perhaps together with?) re-frames subscriptions (so reagents ratoms, really), but in my opinion reliance on local state is a mistake. I'd like to violently agree with you. :-) State in the one place simplifies so much. The moment you have state in multiple places, and that state needs synchronization, you have a problem. The strategy for solving that problem will involve either (1) things watching other things for changes or (2) things telling other things they have changed. The OO paradigm encourages a lot of distributed, synchronized state, and the The Observer pattern is used to handle it. Those that use component local state with OM, have the same issues as the OO paradigm. Sometimes they use a global bus to achieve synconization (things telling other things that something has changed) which is a similar pattern to various OO framemworks, like PureMVC. In the functional programming space, the movement seems to be towards FRP. Data flows into functions and out again, in something of a pipeline. The structure of those flows is more declarative WRT time. The thing is this: synchronization of state is a pain. Have as little of it
Re: [ClojureScript] Using a state machine to design/program UI ?
Data for the win. I remember in the olden days when AOP reared its head and people were talking about retrying updates against stale data/exceptions. I was always/still am a bit cynical because I just don't see that many exceptions where the exception is transient and the second attempt would work. I would be very interested to know how many UHEs are genuinely 'transient', in that they don't happen again when the user tries to do the same thing - do you have any metrics? On 15 May 2015 at 15:56, Mike Thompson m.l.thompson...@gmail.com wrote: On Saturday, May 16, 2015 at 12:36:02 AM UTC+10, Colin Yates wrote: For me, I can't use the 'snapshot app-db and discard' as the app-db is synchronised with the server periodically. As you mention, I have a number of roots in my app, one for 'ui' entries and one for 'views' which are populated by the server, even if I want to discard the 'ui' root I really don't want to discard the 'views'. I avoid local state as well simply because the benefit of being able to capture the whole app-db and attach it to a bug report is awesome. We've now hooked window.onerror and in production, and when there's an unhandled exception, we automatically do an undo, to take the user back to the previous known sane state. It works a treat. (Not that we get many UHE, you understand :-)) It means the user still has a working program (with error message), and hasn't lost anything because of the problem. AND, as you say, we serialise the app-db and the event which caused the UHE, to form the perfect, reproducible bug report. (We also have a log of all previous events too ... because they are pure data). It brings a tear to my eye its so damn beautiful. That all comes almost for free because the data is all in the one place and because events are pure data to boot. -- Mike -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] Using a state machine to design/program UI ?
And that is why they should be compiled, not implemented directly in main language of the project. I've made experimental yEd diagrams → CLJ(S) FSM compiler and executor (https://github.com/ul/vfsm). Simple example of its usage could be found here https://github.com/ul/ampere/tree/master/examples/simple — open resources/example.graphml with yEd (http://www.yworks.com/en/products/yfiles/yed/) to see how control logic of handler is defined. What is the real fun, that it is easy to spot an error in the logic looking on that graph. If you rewrite this state machine in textual code, you will get something harder to inspect. четверг, 14 мая 2015 г., 6:39:02 UTC+3 пользователь Erik Price написал: Finite state machines are a useful modeling tool, but when implemented in code they can involve a lot of boilerplate and complexity. These days I prefer Rx-like paradigms for sophisticated handling of asynchronous events. e On Wed, May 13, 2015 at 5:54 AM, Khalid Jebbari khalid@gmail.com wrote: Hello everyone, As a Javascript web developer, I'm thinking more and more about a good way to design interface so that I don't create a mess. Because I think the current state of the art of web UI development and frameworks is still a big mess. React.js and the CLJS wrapper around them help a bit but not that much I think. My goals are the following : - construct the complete UI logic outside of anything web related, so that it's testable without a browser and usable in other contexts (CLI, back-end, scripts, whatever) - being able to *visualize* the logic without having to read all the code, through diagrams and other means. I've heard in several places that state machines are a good way to handle such cases, since they're inherently event-driven and the web is too. So I start researching. The wikipedia page (https://en.wikipedia.org/wiki/Finite-state_machine) and the various linked pages are very instructive and indeed explain that a FSM can be used to model UI interaction. I found this 3-parts article series from IBM (http://www.ibm.com/developerworks/library/wa-finitemach1/index.html) that implements a tooltip using a state machine. Then I found 2 clojure libs that helps design a state machine : reduce-fsm (https://github.com/cdorrat/reduce-fsm) and automat (https://github.com/ztellman/automat). Both have the *very* nice feature of being able to generate a state diagram from the code, but only automat provides support for CLJS. I think a state machine fits very well with React.js and as so the various CLJS wrappers, since : - in an event-driven state machine, there's a loop listening to events. This event-loop is naturally provided by web browsers - defining strictly and formally the available states helps reduce bugs and maintain the application - the output is always defined by the combination of the input and the current state, which is *exactly* what the render function of React component are about : displaying DOM based only on the state of the component. Since this state is purely data, and CLJ/CLJS are kings when it comes to data, the benefits would be to be able to test the logic a component outside of the DOM and have components that simply emit events (with the associated payload) to the state machines. The various libs in the CLJ/CLJS ecosystem can help greatly : - the aforementioned automat lib to design and visualize a state machine - Prismatic's Schema (https://github.com/Prismatic/schema), Herbert (https://github.com/miner/herbert) and the likes to formally specify data types/shapes that come in and out of the state machine - test.check to generate lots of input to the state machine and check the output. This can't replace UI testing, but can complement it a lot. Note that Herbert is de facto compatible with test.check - The various React.js wrappers to take this state and simply project it to the DOM. This post is basically a reflection on the subject that I wanted to share and not lose in my mind since I'm new to state machines, and a question to the community : did you already use a state machine to program a web UI ? Successfully ? With which tools ? What do you think of the various libs (aka the stack lol) proposed above ? I know that a simple state machine trivially implemented with no libs at all and may seem often overkill. This post from Spotify (https://www.shopify.com/technology/3383012-why-developers-should-be-force-fed-state-machines) and this response (http://www.skorks.com/2011/09/why-developers-never-use-state-machines/) are really interested real world examples of usage (or not) of state machines. Phew ! It was long, I hope I wasn't boring and I'm looking forward to your answers. Let's discuss ! -- Note that posts from new members are moderated - please be patient
Re: [ClojureScript] Using a state machine to design/program UI ?
This is really interesting stuff. I'd looked over Hoplon a year ago and didn't use it as it wasn't React-based. I really liked the spread-sheet/cell metaphor. I wish I had more time to explore all of these libs! :) CLJS is enjoying quite a Cambrian explosion of interesting libraries. Jamie On May 14, 2015, at 2:26 PM, Ruslan Prokopchuk fer.ob...@gmail.com wrote: Jamie, exactly, I took re-frame (it's awesome!) and replaced subscriptions mechanism with Javelin cells. I like Javelin, it allows elegant and succinct data coordination. See todomvc example in the amper and re-frame repos for comparison. Also I've replaced Reagent with Om because of my internal needs, but re-frame architecture is View-agnostic in its heart, and I've implemented it in ampere. Now it includes only Om adapter, but more to come with examples (I plan to make todomvc views.cljs port for every supported View library). Hoplon does not require any adapter at all, for example ;-) -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] Using a state machine to design/program UI ?
Jamie, exactly, I took re-frame (it's awesome!) and replaced subscriptions mechanism with Javelin cells. I like Javelin, it allows elegant and succinct data coordination. See todomvc example in the amper and re-frame repos for comparison. Also I've replaced Reagent with Om because of my internal needs, but re-frame architecture is View-agnostic in its heart, and I've implemented it in ampere. Now it includes only Om adapter, but more to come with examples (I plan to make todomvc views.cljs port for every supported View library). Hoplon does not require any adapter at all, for example ;-) -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] Using a state machine to design/program UI ?
Ruslan, I haven't look at the code or tried your example. But being able to draw the program's logic and have it executed is even more than awesome. I'm not sure whether graph-to-code like what you did, or code-to-graph like what automat or Kevin's (from this thread) work do is better, but simply knowing that both are possible in the CLJ(S) world... I'm happy I started this thread. Khalid aka DjebbZ @Dj3bbZ On Thu, May 14, 2015 at 3:45 PM, Ruslan Prokopchuk fer.ob...@gmail.com wrote: And that is why they should be compiled, not implemented directly in main language of the project. I've made experimental yEd diagrams → CLJ(S) FSM compiler and executor (https://github.com/ul/vfsm). Simple example of its usage could be found here https://github.com/ul/ampere/tree/master/examples/simple — open resources/example.graphml with yEd ( http://www.yworks.com/en/products/yfiles/yed/) to see how control logic of handler is defined. What is the real fun, that it is easy to spot an error in the logic looking on that graph. If you rewrite this state machine in textual code, you will get something harder to inspect. четверг, 14 мая 2015 г., 6:39:02 UTC+3 пользователь Erik Price написал: Finite state machines are a useful modeling tool, but when implemented in code they can involve a lot of boilerplate and complexity. These days I prefer Rx-like paradigms for sophisticated handling of asynchronous events. e On Wed, May 13, 2015 at 5:54 AM, Khalid Jebbari khalid@gmail.com wrote: Hello everyone, As a Javascript web developer, I'm thinking more and more about a good way to design interface so that I don't create a mess. Because I think the current state of the art of web UI development and frameworks is still a big mess. React.js and the CLJS wrapper around them help a bit but not that much I think. My goals are the following : - construct the complete UI logic outside of anything web related, so that it's testable without a browser and usable in other contexts (CLI, back-end, scripts, whatever) - being able to *visualize* the logic without having to read all the code, through diagrams and other means. I've heard in several places that state machines are a good way to handle such cases, since they're inherently event-driven and the web is too. So I start researching. The wikipedia page ( https://en.wikipedia.org/wiki/Finite-state_machine) and the various linked pages are very instructive and indeed explain that a FSM can be used to model UI interaction. I found this 3-parts article series from IBM ( http://www.ibm.com/developerworks/library/wa-finitemach1/index.html) that implements a tooltip using a state machine. Then I found 2 clojure libs that helps design a state machine : reduce-fsm (https://github.com/cdorrat/reduce-fsm) and automat ( https://github.com/ztellman/automat). Both have the *very* nice feature of being able to generate a state diagram from the code, but only automat provides support for CLJS. I think a state machine fits very well with React.js and as so the various CLJS wrappers, since : - in an event-driven state machine, there's a loop listening to events. This event-loop is naturally provided by web browsers - defining strictly and formally the available states helps reduce bugs and maintain the application - the output is always defined by the combination of the input and the current state, which is *exactly* what the render function of React component are about : displaying DOM based only on the state of the component. Since this state is purely data, and CLJ/CLJS are kings when it comes to data, the benefits would be to be able to test the logic a component outside of the DOM and have components that simply emit events (with the associated payload) to the state machines. The various libs in the CLJ/CLJS ecosystem can help greatly : - the aforementioned automat lib to design and visualize a state machine - Prismatic's Schema (https://github.com/Prismatic/schema), Herbert ( https://github.com/miner/herbert) and the likes to formally specify data types/shapes that come in and out of the state machine - test.check to generate lots of input to the state machine and check the output. This can't replace UI testing, but can complement it a lot. Note that Herbert is de facto compatible with test.check - The various React.js wrappers to take this state and simply project it to the DOM. This post is basically a reflection on the subject that I wanted to share and not lose in my mind since I'm new to state machines, and a question to the community : did you already use a state machine to program a web UI ? Successfully ? With which tools ? What do you think of the various libs (aka the stack lol) proposed above ? I know that a simple state machine trivially implemented with no libs at all and may seem often
Re: [ClojureScript] Using a state machine to design/program UI ?
Ruslan, ampere looks interesting. You've taken the handler/middleware code from re-frame and combined with javelin to make ampere. Is that a fair assessment? I'll have to have a look at javelin. Jamie On May 14, 2015, at 9:45 AM, Ruslan Prokopchuk fer.ob...@gmail.com wrote: And that is why they should be compiled, not implemented directly in main language of the project. I've made experimental yEd diagrams → CLJ(S) FSM compiler and executor (https://github.com/ul/vfsm). Simple example of its usage could be found here https://github.com/ul/ampere/tree/master/examples/simple — open resources/example.graphml with yEd (http://www.yworks.com/en/products/yfiles/yed/) to see how control logic of handler is defined. What is the real fun, that it is easy to spot an error in the logic looking on that graph. If you rewrite this state machine in textual code, you will get something harder to inspect. четверг, 14 мая 2015 г., 6:39:02 UTC+3 пользователь Erik Price написал: Finite state machines are a useful modeling tool, but when implemented in code they can involve a lot of boilerplate and complexity. These days I prefer Rx-like paradigms for sophisticated handling of asynchronous events. e On Wed, May 13, 2015 at 5:54 AM, Khalid Jebbari khalid@gmail.com wrote: Hello everyone, As a Javascript web developer, I'm thinking more and more about a good way to design interface so that I don't create a mess. Because I think the current state of the art of web UI development and frameworks is still a big mess. React.js and the CLJS wrapper around them help a bit but not that much I think. My goals are the following : - construct the complete UI logic outside of anything web related, so that it's testable without a browser and usable in other contexts (CLI, back-end, scripts, whatever) - being able to *visualize* the logic without having to read all the code, through diagrams and other means. I've heard in several places that state machines are a good way to handle such cases, since they're inherently event-driven and the web is too. So I start researching. The wikipedia page (https://en.wikipedia.org/wiki/Finite-state_machine) and the various linked pages are very instructive and indeed explain that a FSM can be used to model UI interaction. I found this 3-parts article series from IBM (http://www.ibm.com/developerworks/library/wa-finitemach1/index.html) that implements a tooltip using a state machine. Then I found 2 clojure libs that helps design a state machine : reduce-fsm (https://github.com/cdorrat/reduce-fsm) and automat (https://github.com/ztellman/automat). Both have the *very* nice feature of being able to generate a state diagram from the code, but only automat provides support for CLJS. I think a state machine fits very well with React.js and as so the various CLJS wrappers, since : - in an event-driven state machine, there's a loop listening to events. This event-loop is naturally provided by web browsers - defining strictly and formally the available states helps reduce bugs and maintain the application - the output is always defined by the combination of the input and the current state, which is *exactly* what the render function of React component are about : displaying DOM based only on the state of the component. Since this state is purely data, and CLJ/CLJS are kings when it comes to data, the benefits would be to be able to test the logic a component outside of the DOM and have components that simply emit events (with the associated payload) to the state machines. The various libs in the CLJ/CLJS ecosystem can help greatly : - the aforementioned automat lib to design and visualize a state machine - Prismatic's Schema (https://github.com/Prismatic/schema), Herbert (https://github.com/miner/herbert) and the likes to formally specify data types/shapes that come in and out of the state machine - test.check to generate lots of input to the state machine and check the output. This can't replace UI testing, but can complement it a lot. Note that Herbert is de facto compatible with test.check - The various React.js wrappers to take this state and simply project it to the DOM. This post is basically a reflection on the subject that I wanted to share and not lose in my mind since I'm new to state machines, and a question to the community : did you already use a state machine to program a web UI ? Successfully ? With which tools ? What do you think of the various libs (aka the stack lol) proposed above ? I know that a simple state machine trivially implemented with no libs at all and may seem often overkill. This post from Spotify (https://www.shopify.com/technology/3383012-why-developers-should-be-force-fed-state-machines) and this response
Re: [ClojureScript] Using a state machine to design/program UI ?
Reagent's create class allows normal React lifecycle callbacks without any verboseness. However, the big surprise for me was finding out that both Reagent and Om use async updates for everything when React has problems with it in some cases, like controlled inputs. http://jonase.github.io/nil-recur/posts/14-12-2014-controlled-input.html Dan Homlsand (Reagent's author) is looking into it, so we'll see what he'll come back with. I might be naive here but I'm hoping that we can use async setState for all updates except for controlled inputs. Sent from my iPhone On May 14, 2015, at 1:20 PM, Jamie Orchard-Hays jamie...@gmail.com wrote: No kidding. I have this long blog post germinating in my head about my experiences with Om and re-frame now that I've developed a reasonably-sized app in each. Problem is, I have no time to write it. One thing I've come to appreciate about Om over Reagent is that despite it being more verbose, it's always clear where you are WRT the React lifecycle and state. Reagent, being less formal, lends itself to some confusion over what's happening where. In general, I agree with some comments I've seen in this group recently that we really have a long way to go with rich client web apps. It's still way too time-consuming, painful and not formalized enough, even with the awesome tools we have around already. Simple *and* easy is the brass ring. On May 14, 2015, at 3:35 PM, Colin Yates colin.ya...@gmail.com wrote: +1 I keep thinking yeah, this is the stack I will use, let's invest in this then something new comes along. Not good for those of use affected with grassisalwaysgreeneritus :). On 14 May 2015 19:39, Jamie Orchard-Hays jamie...@gmail.com wrote: This is really interesting stuff. I'd looked over Hoplon a year ago and didn't use it as it wasn't React-based. I really liked the spread-sheet/cell metaphor. I wish I had more time to explore all of these libs! :) CLJS is enjoying quite a Cambrian explosion of interesting libraries. Jamie On May 14, 2015, at 2:26 PM, Ruslan Prokopchuk fer.ob...@gmail.com wrote: Jamie, exactly, I took re-frame (it's awesome!) and replaced subscriptions mechanism with Javelin cells. I like Javelin, it allows elegant and succinct data coordination. See todomvc example in the amper and re-frame repos for comparison. Also I've replaced Reagent with Om because of my internal needs, but re-frame architecture is View-agnostic in its heart, and I've implemented it in ampere. Now it includes only Om adapter, but more to come with examples (I plan to make todomvc views.cljs port for every supported View library). Hoplon does not require any adapter at all, for example ;-) -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email
Re: [ClojureScript] Using a state machine to design/program UI ?
Generating a functional state machine from a diagram is awesome. Generating a diagram from the code of a state machine is awesome too. But state diagram are only 1 of the 2 visual representations of state machines AFAIK. The other is the state transition table : https://en.wikipedia.org/wiki/State_transition_table I already opened an issue to the automat repo, hoping Zach Tellman will consider generating the table from the code being a good idea. And also in Ruslan's vfsm to generate a state machine from a table. Visual programming for the win, really. Khalid aka DjebbZ @Dj3bbZ On Thu, May 14, 2015 at 10:20 PM, Jamie Orchard-Hays jamie...@gmail.com wrote: No kidding. I have this long blog post germinating in my head about my experiences with Om and re-frame now that I've developed a reasonably-sized app in each. Problem is, I have no time to write it. One thing I've come to appreciate about Om over Reagent is that despite it being more verbose, it's always clear where you are WRT the React lifecycle and state. Reagent, being less formal, lends itself to some confusion over what's happening where. In general, I agree with some comments I've seen in this group recently that we really have a long way to go with rich client web apps. It's still way too time-consuming, painful and not formalized enough, even with the awesome tools we have around already. Simple *and* easy is the brass ring. On May 14, 2015, at 3:35 PM, Colin Yates colin.ya...@gmail.com wrote: +1 I keep thinking yeah, this is the stack I will use, let's invest in this then something new comes along. Not good for those of use affected with grassisalwaysgreeneritus :). On 14 May 2015 19:39, Jamie Orchard-Hays jamie...@gmail.com wrote: This is really interesting stuff. I'd looked over Hoplon a year ago and didn't use it as it wasn't React-based. I really liked the spread-sheet/cell metaphor. I wish I had more time to explore all of these libs! :) CLJS is enjoying quite a Cambrian explosion of interesting libraries. Jamie On May 14, 2015, at 2:26 PM, Ruslan Prokopchuk fer.ob...@gmail.com wrote: Jamie, exactly, I took re-frame (it's awesome!) and replaced subscriptions mechanism with Javelin cells. I like Javelin, it allows elegant and succinct data coordination. See todomvc example in the amper and re-frame repos for comparison. Also I've replaced Reagent with Om because of my internal needs, but re-frame architecture is View-agnostic in its heart, and I've implemented it in ampere. Now it includes only Om adapter, but more to come with examples (I plan to make todomvc views.cljs port for every supported View library). Hoplon does not require any adapter at all, for example ;-) -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to a topic in the Google Groups ClojureScript group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojurescript/7STtgK5QiIc/unsubscribe. To unsubscribe from this group and all its topics, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to
Re: [ClojureScript] Using a state machine to design/program UI ?
+1 I keep thinking yeah, this is the stack I will use, let's invest in this then something new comes along. Not good for those of use affected with grassisalwaysgreeneritus :). On 14 May 2015 19:39, Jamie Orchard-Hays jamie...@gmail.com wrote: This is really interesting stuff. I'd looked over Hoplon a year ago and didn't use it as it wasn't React-based. I really liked the spread-sheet/cell metaphor. I wish I had more time to explore all of these libs! :) CLJS is enjoying quite a Cambrian explosion of interesting libraries. Jamie On May 14, 2015, at 2:26 PM, Ruslan Prokopchuk fer.ob...@gmail.com wrote: Jamie, exactly, I took re-frame (it's awesome!) and replaced subscriptions mechanism with Javelin cells. I like Javelin, it allows elegant and succinct data coordination. See todomvc example in the amper and re-frame repos for comparison. Also I've replaced Reagent with Om because of my internal needs, but re-frame architecture is View-agnostic in its heart, and I've implemented it in ampere. Now it includes only Om adapter, but more to come with examples (I plan to make todomvc views.cljs port for every supported View library). Hoplon does not require any adapter at all, for example ;-) -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] Using a state machine to design/program UI ?
Interesting article. Pondering if some of my struggles have been around that issue, but not sure off the top of my head. I've definitely used Reagent's create-class on a couple of complex components. Jamie On May 14, 2015, at 5:01 PM, Marc Fawzi marc.fa...@gmail.com wrote: Reagent's create class allows normal React lifecycle callbacks without any verboseness. However, the big surprise for me was finding out that both Reagent and Om use async updates for everything when React has problems with it in some cases, like controlled inputs. http://jonase.github.io/nil-recur/posts/14-12-2014-controlled-input.html Dan Homlsand (Reagent's author) is looking into it, so we'll see what he'll come back with. I might be naive here but I'm hoping that we can use async setState for all updates except for controlled inputs. Sent from my iPhone On May 14, 2015, at 1:20 PM, Jamie Orchard-Hays jamie...@gmail.com wrote: No kidding. I have this long blog post germinating in my head about my experiences with Om and re-frame now that I've developed a reasonably-sized app in each. Problem is, I have no time to write it. One thing I've come to appreciate about Om over Reagent is that despite it being more verbose, it's always clear where you are WRT the React lifecycle and state. Reagent, being less formal, lends itself to some confusion over what's happening where. In general, I agree with some comments I've seen in this group recently that we really have a long way to go with rich client web apps. It's still way too time-consuming, painful and not formalized enough, even with the awesome tools we have around already. Simple *and* easy is the brass ring. On May 14, 2015, at 3:35 PM, Colin Yates colin.ya...@gmail.com wrote: +1 I keep thinking yeah, this is the stack I will use, let's invest in this then something new comes along. Not good for those of use affected with grassisalwaysgreeneritus :). On 14 May 2015 19:39, Jamie Orchard-Hays jamie...@gmail.com wrote: This is really interesting stuff. I'd looked over Hoplon a year ago and didn't use it as it wasn't React-based. I really liked the spread-sheet/cell metaphor. I wish I had more time to explore all of these libs! :) CLJS is enjoying quite a Cambrian explosion of interesting libraries. Jamie On May 14, 2015, at 2:26 PM, Ruslan Prokopchuk fer.ob...@gmail.com wrote: Jamie, exactly, I took re-frame (it's awesome!) and replaced subscriptions mechanism with Javelin cells. I like Javelin, it allows elegant and succinct data coordination. See todomvc example in the amper and re-frame repos for comparison. Also I've replaced Reagent with Om because of my internal needs, but re-frame architecture is View-agnostic in its heart, and I've implemented it in ampere. Now it includes only Om adapter, but more to come with examples (I plan to make todomvc views.cljs port for every supported View library). Hoplon does not require any adapter at all, for example ;-) -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated -
Re: [ClojureScript] Using a state machine to design/program UI ?
I'm still in the early stages of digesting Javelin, but one idea I keep having is using it locally in components to make subscriptions that are otherwise global using reframe. On May 14, 2015, at 4:20 PM, Jamie Orchard-Hays jamie...@gmail.com wrote: No kidding. I have this long blog post germinating in my head about my experiences with Om and re-frame now that I've developed a reasonably-sized app in each. Problem is, I have no time to write it. One thing I've come to appreciate about Om over Reagent is that despite it being more verbose, it's always clear where you are WRT the React lifecycle and state. Reagent, being less formal, lends itself to some confusion over what's happening where. In general, I agree with some comments I've seen in this group recently that we really have a long way to go with rich client web apps. It's still way too time-consuming, painful and not formalized enough, even with the awesome tools we have around already. Simple *and* easy is the brass ring. On May 14, 2015, at 3:35 PM, Colin Yates colin.ya...@gmail.com wrote: +1 I keep thinking yeah, this is the stack I will use, let's invest in this then something new comes along. Not good for those of use affected with grassisalwaysgreeneritus :). On 14 May 2015 19:39, Jamie Orchard-Hays jamie...@gmail.com wrote: This is really interesting stuff. I'd looked over Hoplon a year ago and didn't use it as it wasn't React-based. I really liked the spread-sheet/cell metaphor. I wish I had more time to explore all of these libs! :) CLJS is enjoying quite a Cambrian explosion of interesting libraries. Jamie On May 14, 2015, at 2:26 PM, Ruslan Prokopchuk fer.ob...@gmail.com wrote: Jamie, exactly, I took re-frame (it's awesome!) and replaced subscriptions mechanism with Javelin cells. I like Javelin, it allows elegant and succinct data coordination. See todomvc example in the amper and re-frame repos for comparison. Also I've replaced Reagent with Om because of my internal needs, but re-frame architecture is View-agnostic in its heart, and I've implemented it in ampere. Now it includes only Om adapter, but more to come with examples (I plan to make todomvc views.cljs port for every supported View library). Hoplon does not require any adapter at all, for example ;-) -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] Using a state machine to design/program UI ?
Personally I find that moving state out of components as re-frame's subscriptions and handlers encourage is a desirable trait and would be cautious about reintroducing local state. Keeping my data in one place (and handling updates and queries through a centralised place) has made it a lot easier for me to manage complex data and logic. I've played with javelin in the past and it's a fantastic library. I quite like the idea of using it as a replacement for (or perhaps together with?) re-frames subscriptions (so reagents ratoms, really), but in my opinion reliance on local state is a mistake. Having said that, I'd love to hear counterpoints. I'm quite interested in the topic of using state machines too. As re-frames readme mentions, app-db updates can be thought of as state transitions, but I think having well defined named states is a good idea as it's very difficult to determine what state your application is in by looking at it's data for any non trivial application. I also like the idea of knowing in advance what the valid transitions from any given state are as it's useful for generative testing and debugging and overall understanding of supplication logic. I'm currently mulling over the idea of combining re-frames app-db with a state machine (perhaps using automat). I feel like maybe a hybrid approach could work well, but an unsure how it would look. On Thu, 14 May 2015 22:34 Jamie Orchard-Hays jamie...@gmail.com wrote: I'm still in the early stages of digesting Javelin, but one idea I keep having is using it locally in components to make subscriptions that are otherwise global using reframe. On May 14, 2015, at 4:20 PM, Jamie Orchard-Hays jamie...@gmail.com wrote: No kidding. I have this long blog post germinating in my head about my experiences with Om and re-frame now that I've developed a reasonably-sized app in each. Problem is, I have no time to write it. One thing I've come to appreciate about Om over Reagent is that despite it being more verbose, it's always clear where you are WRT the React lifecycle and state. Reagent, being less formal, lends itself to some confusion over what's happening where. In general, I agree with some comments I've seen in this group recently that we really have a long way to go with rich client web apps. It's still way too time-consuming, painful and not formalized enough, even with the awesome tools we have around already. Simple *and* easy is the brass ring. On May 14, 2015, at 3:35 PM, Colin Yates colin.ya...@gmail.com wrote: +1 I keep thinking yeah, this is the stack I will use, let's invest in this then something new comes along. Not good for those of use affected with grassisalwaysgreeneritus :). On 14 May 2015 19:39, Jamie Orchard-Hays jamie...@gmail.com wrote: This is really interesting stuff. I'd looked over Hoplon a year ago and didn't use it as it wasn't React-based. I really liked the spread-sheet/cell metaphor. I wish I had more time to explore all of these libs! :) CLJS is enjoying quite a Cambrian explosion of interesting libraries. Jamie On May 14, 2015, at 2:26 PM, Ruslan Prokopchuk fer.ob...@gmail.com wrote: Jamie, exactly, I took re-frame (it's awesome!) and replaced subscriptions mechanism with Javelin cells. I like Javelin, it allows elegant and succinct data coordination. See todomvc example in the amper and re-frame repos for comparison. Also I've replaced Reagent with Om because of my internal needs, but re-frame architecture is View-agnostic in its heart, and I've implemented it in ampere. Now it includes only Om adapter, but more to come with examples (I plan to make todomvc views.cljs port for every supported View library). Hoplon does not require any adapter at all, for example ;-) -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to
Re: [ClojureScript] Using a state machine to design/program UI ?
Actually, I'm interested in local transitions (cell=) rather than local state. That is, a view may be interested in transitions that only apply to itself. I like the idea of encapsulating those transitions into the view itself. re-frame's subscriptions are inherently global, at least to whichever namespaces have required the subscriptions. This offers better encapsulation as I understand them. Jamie On May 14, 2015, at 8:27 PM, Daniel Kersten dkers...@gmail.com wrote: Personally I find that moving state out of components as re-frame's subscriptions and handlers encourage is a desirable trait and would be cautious about reintroducing local state. Keeping my data in one place (and handling updates and queries through a centralised place) has made it a lot easier for me to manage complex data and logic. I've played with javelin in the past and it's a fantastic library. I quite like the idea of using it as a replacement for (or perhaps together with?) re-frames subscriptions (so reagents ratoms, really), but in my opinion reliance on local state is a mistake. Having said that, I'd love to hear counterpoints. I'm quite interested in the topic of using state machines too. As re-frames readme mentions, app-db updates can be thought of as state transitions, but I think having well defined named states is a good idea as it's very difficult to determine what state your application is in by looking at it's data for any non trivial application. I also like the idea of knowing in advance what the valid transitions from any given state are as it's useful for generative testing and debugging and overall understanding of supplication logic. I'm currently mulling over the idea of combining re-frames app-db with a state machine (perhaps using automat). I feel like maybe a hybrid approach could work well, but an unsure how it would look. On Thu, 14 May 2015 22:34 Jamie Orchard-Hays jamie...@gmail.com wrote: I'm still in the early stages of digesting Javelin, but one idea I keep having is using it locally in components to make subscriptions that are otherwise global using reframe. On May 14, 2015, at 4:20 PM, Jamie Orchard-Hays jamie...@gmail.com wrote: No kidding. I have this long blog post germinating in my head about my experiences with Om and re-frame now that I've developed a reasonably-sized app in each. Problem is, I have no time to write it. One thing I've come to appreciate about Om over Reagent is that despite it being more verbose, it's always clear where you are WRT the React lifecycle and state. Reagent, being less formal, lends itself to some confusion over what's happening where. In general, I agree with some comments I've seen in this group recently that we really have a long way to go with rich client web apps. It's still way too time-consuming, painful and not formalized enough, even with the awesome tools we have around already. Simple *and* easy is the brass ring. On May 14, 2015, at 3:35 PM, Colin Yates colin.ya...@gmail.com wrote: +1 I keep thinking yeah, this is the stack I will use, let's invest in this then something new comes along. Not good for those of use affected with grassisalwaysgreeneritus :). On 14 May 2015 19:39, Jamie Orchard-Hays jamie...@gmail.com wrote: This is really interesting stuff. I'd looked over Hoplon a year ago and didn't use it as it wasn't React-based. I really liked the spread-sheet/cell metaphor. I wish I had more time to explore all of these libs! :) CLJS is enjoying quite a Cambrian explosion of interesting libraries. Jamie On May 14, 2015, at 2:26 PM, Ruslan Prokopchuk fer.ob...@gmail.com wrote: Jamie, exactly, I took re-frame (it's awesome!) and replaced subscriptions mechanism with Javelin cells. I like Javelin, it allows elegant and succinct data coordination. See todomvc example in the amper and re-frame repos for comparison. Also I've replaced Reagent with Om because of my internal needs, but re-frame architecture is View-agnostic in its heart, and I've implemented it in ampere. Now it includes only Om adapter, but more to come with examples (I plan to make todomvc views.cljs port for every supported View library). Hoplon does not require any adapter at all, for example ;-) -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups
Re: [ClojureScript] Using a state machine to design/program UI ?
Speaking of Cambrian Explosion, I saw in the latest LispCast a link to a new React CLJS lib from weavejester called Brutha: https://github.com/weavejester/brutha Jamie On May 14, 2015, at 8:54 PM, Jamie Orchard-Hays jamie...@gmail.com wrote: Actually, I'm interested in local transitions (cell=) rather than local state. That is, a view may be interested in transitions that only apply to itself. I like the idea of encapsulating those transitions into the view itself. re-frame's subscriptions are inherently global, at least to whichever namespaces have required the subscriptions. This offers better encapsulation as I understand them. Jamie On May 14, 2015, at 8:27 PM, Daniel Kersten dkers...@gmail.com wrote: Personally I find that moving state out of components as re-frame's subscriptions and handlers encourage is a desirable trait and would be cautious about reintroducing local state. Keeping my data in one place (and handling updates and queries through a centralised place) has made it a lot easier for me to manage complex data and logic. I've played with javelin in the past and it's a fantastic library. I quite like the idea of using it as a replacement for (or perhaps together with?) re-frames subscriptions (so reagents ratoms, really), but in my opinion reliance on local state is a mistake. Having said that, I'd love to hear counterpoints. I'm quite interested in the topic of using state machines too. As re-frames readme mentions, app-db updates can be thought of as state transitions, but I think having well defined named states is a good idea as it's very difficult to determine what state your application is in by looking at it's data for any non trivial application. I also like the idea of knowing in advance what the valid transitions from any given state are as it's useful for generative testing and debugging and overall understanding of supplication logic. I'm currently mulling over the idea of combining re-frames app-db with a state machine (perhaps using automat). I feel like maybe a hybrid approach could work well, but an unsure how it would look. On Thu, 14 May 2015 22:34 Jamie Orchard-Hays jamie...@gmail.com wrote: I'm still in the early stages of digesting Javelin, but one idea I keep having is using it locally in components to make subscriptions that are otherwise global using reframe. On May 14, 2015, at 4:20 PM, Jamie Orchard-Hays jamie...@gmail.com wrote: No kidding. I have this long blog post germinating in my head about my experiences with Om and re-frame now that I've developed a reasonably-sized app in each. Problem is, I have no time to write it. One thing I've come to appreciate about Om over Reagent is that despite it being more verbose, it's always clear where you are WRT the React lifecycle and state. Reagent, being less formal, lends itself to some confusion over what's happening where. In general, I agree with some comments I've seen in this group recently that we really have a long way to go with rich client web apps. It's still way too time-consuming, painful and not formalized enough, even with the awesome tools we have around already. Simple *and* easy is the brass ring. On May 14, 2015, at 3:35 PM, Colin Yates colin.ya...@gmail.com wrote: +1 I keep thinking yeah, this is the stack I will use, let's invest in this then something new comes along. Not good for those of use affected with grassisalwaysgreeneritus :). On 14 May 2015 19:39, Jamie Orchard-Hays jamie...@gmail.com wrote: This is really interesting stuff. I'd looked over Hoplon a year ago and didn't use it as it wasn't React-based. I really liked the spread-sheet/cell metaphor. I wish I had more time to explore all of these libs! :) CLJS is enjoying quite a Cambrian explosion of interesting libraries. Jamie On May 14, 2015, at 2:26 PM, Ruslan Prokopchuk fer.ob...@gmail.com wrote: Jamie, exactly, I took re-frame (it's awesome!) and replaced subscriptions mechanism with Javelin cells. I like Javelin, it allows elegant and succinct data coordination. See todomvc example in the amper and re-frame repos for comparison. Also I've replaced Reagent with Om because of my internal needs, but re-frame architecture is View-agnostic in its heart, and I've implemented it in ampere. Now it includes only Om adapter, but more to come with examples (I plan to make todomvc views.cljs port for every supported View library). Hoplon does not require any adapter at all, for example ;-) -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to
Re: [ClojureScript] Using a state machine to design/program UI ?
Thanks Brutha! :) Sent from my iPhone On May 14, 2015, at 6:11 PM, Jamie Orchard-Hays jamie...@gmail.com wrote: Speaking of Cambrian Explosion, I saw in the latest LispCast a link to a new React CLJS lib from weavejester called Brutha: https://github.com/weavejester/brutha Jamie On May 14, 2015, at 8:54 PM, Jamie Orchard-Hays jamie...@gmail.com wrote: Actually, I'm interested in local transitions (cell=) rather than local state. That is, a view may be interested in transitions that only apply to itself. I like the idea of encapsulating those transitions into the view itself. re-frame's subscriptions are inherently global, at least to whichever namespaces have required the subscriptions. This offers better encapsulation as I understand them. Jamie On May 14, 2015, at 8:27 PM, Daniel Kersten dkers...@gmail.com wrote: Personally I find that moving state out of components as re-frame's subscriptions and handlers encourage is a desirable trait and would be cautious about reintroducing local state. Keeping my data in one place (and handling updates and queries through a centralised place) has made it a lot easier for me to manage complex data and logic. I've played with javelin in the past and it's a fantastic library. I quite like the idea of using it as a replacement for (or perhaps together with?) re-frames subscriptions (so reagents ratoms, really), but in my opinion reliance on local state is a mistake. Having said that, I'd love to hear counterpoints. I'm quite interested in the topic of using state machines too. As re-frames readme mentions, app-db updates can be thought of as state transitions, but I think having well defined named states is a good idea as it's very difficult to determine what state your application is in by looking at it's data for any non trivial application. I also like the idea of knowing in advance what the valid transitions from any given state are as it's useful for generative testing and debugging and overall understanding of supplication logic. I'm currently mulling over the idea of combining re-frames app-db with a state machine (perhaps using automat). I feel like maybe a hybrid approach could work well, but an unsure how it would look. On Thu, 14 May 2015 22:34 Jamie Orchard-Hays jamie...@gmail.com wrote: I'm still in the early stages of digesting Javelin, but one idea I keep having is using it locally in components to make subscriptions that are otherwise global using reframe. On May 14, 2015, at 4:20 PM, Jamie Orchard-Hays jamie...@gmail.com wrote: No kidding. I have this long blog post germinating in my head about my experiences with Om and re-frame now that I've developed a reasonably-sized app in each. Problem is, I have no time to write it. One thing I've come to appreciate about Om over Reagent is that despite it being more verbose, it's always clear where you are WRT the React lifecycle and state. Reagent, being less formal, lends itself to some confusion over what's happening where. In general, I agree with some comments I've seen in this group recently that we really have a long way to go with rich client web apps. It's still way too time-consuming, painful and not formalized enough, even with the awesome tools we have around already. Simple *and* easy is the brass ring. On May 14, 2015, at 3:35 PM, Colin Yates colin.ya...@gmail.com wrote: +1 I keep thinking yeah, this is the stack I will use, let's invest in this then something new comes along. Not good for those of use affected with grassisalwaysgreeneritus :). On 14 May 2015 19:39, Jamie Orchard-Hays jamie...@gmail.com wrote: This is really interesting stuff. I'd looked over Hoplon a year ago and didn't use it as it wasn't React-based. I really liked the spread-sheet/cell metaphor. I wish I had more time to explore all of these libs! :) CLJS is enjoying quite a Cambrian explosion of interesting libraries. Jamie On May 14, 2015, at 2:26 PM, Ruslan Prokopchuk fer.ob...@gmail.com wrote: Jamie, exactly, I took re-frame (it's awesome!) and replaced subscriptions mechanism with Javelin cells. I like Javelin, it allows elegant and succinct data coordination. See todomvc example in the amper and re-frame repos for comparison. Also I've replaced Reagent with Om because of my internal needs, but re-frame architecture is View-agnostic in its heart, and I've implemented it in ampere. Now it includes only Om adapter, but more to come with examples (I plan to make todomvc views.cljs port for every supported View library). Hoplon does not require any adapter at all, for example ;-) -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving
Re: [ClojureScript] Using a state machine to design/program UI ?
In the case of global app state combined with a state machine, where would the URL be stored ? Should it be considered a trigger/event of the state machine ? Should it be stored in the state as any other data ? Le 15 mai 2015 à 03:22, Marc Fawzi marc.fa...@gmail.com a écrit : Thanks Brutha! :) Sent from my iPhone On May 14, 2015, at 6:11 PM, Jamie Orchard-Hays jamie...@gmail.com wrote: Speaking of Cambrian Explosion, I saw in the latest LispCast a link to a new React CLJS lib from weavejester called Brutha: https://github.com/weavejester/brutha Jamie On May 14, 2015, at 8:54 PM, Jamie Orchard-Hays jamie...@gmail.com wrote: Actually, I'm interested in local transitions (cell=) rather than local state. That is, a view may be interested in transitions that only apply to itself. I like the idea of encapsulating those transitions into the view itself. re-frame's subscriptions are inherently global, at least to whichever namespaces have required the subscriptions. This offers better encapsulation as I understand them. Jamie On May 14, 2015, at 8:27 PM, Daniel Kersten dkers...@gmail.com wrote: Personally I find that moving state out of components as re-frame's subscriptions and handlers encourage is a desirable trait and would be cautious about reintroducing local state. Keeping my data in one place (and handling updates and queries through a centralised place) has made it a lot easier for me to manage complex data and logic. I've played with javelin in the past and it's a fantastic library. I quite like the idea of using it as a replacement for (or perhaps together with?) re-frames subscriptions (so reagents ratoms, really), but in my opinion reliance on local state is a mistake. Having said that, I'd love to hear counterpoints. I'm quite interested in the topic of using state machines too. As re-frames readme mentions, app-db updates can be thought of as state transitions, but I think having well defined named states is a good idea as it's very difficult to determine what state your application is in by looking at it's data for any non trivial application. I also like the idea of knowing in advance what the valid transitions from any given state are as it's useful for generative testing and debugging and overall understanding of supplication logic. I'm currently mulling over the idea of combining re-frames app-db with a state machine (perhaps using automat). I feel like maybe a hybrid approach could work well, but an unsure how it would look. On Thu, 14 May 2015 22:34 Jamie Orchard-Hays jamie...@gmail.com wrote: I'm still in the early stages of digesting Javelin, but one idea I keep having is using it locally in components to make subscriptions that are otherwise global using reframe. On May 14, 2015, at 4:20 PM, Jamie Orchard-Hays jamie...@gmail.com wrote: No kidding. I have this long blog post germinating in my head about my experiences with Om and re-frame now that I've developed a reasonably-sized app in each. Problem is, I have no time to write it. One thing I've come to appreciate about Om over Reagent is that despite it being more verbose, it's always clear where you are WRT the React lifecycle and state. Reagent, being less formal, lends itself to some confusion over what's happening where. In general, I agree with some comments I've seen in this group recently that we really have a long way to go with rich client web apps. It's still way too time-consuming, painful and not formalized enough, even with the awesome tools we have around already. Simple *and* easy is the brass ring. On May 14, 2015, at 3:35 PM, Colin Yates colin.ya...@gmail.com wrote: +1 I keep thinking yeah, this is the stack I will use, let's invest in this then something new comes along. Not good for those of use affected with grassisalwaysgreeneritus :). On 14 May 2015 19:39, Jamie Orchard-Hays jamie...@gmail.com wrote: This is really interesting stuff. I'd looked over Hoplon a year ago and didn't use it as it wasn't React-based. I really liked the spread-sheet/cell metaphor. I wish I had more time to explore all of these libs! :) CLJS is enjoying quite a Cambrian explosion of interesting libraries. Jamie On May 14, 2015, at 2:26 PM, Ruslan Prokopchuk fer.ob...@gmail.com wrote: Jamie, exactly, I took re-frame (it's awesome!) and replaced subscriptions mechanism with Javelin cells. I like Javelin, it allows elegant and succinct data coordination. See todomvc example in the amper and re-frame repos for comparison. Also I've replaced Reagent with Om because of my internal needs, but re-frame architecture is View-agnostic in its heart, and I've implemented it in ampere. Now it includes only Om adapter, but more to come with examples (I plan to make todomvc views.cljs port for every supported View library). Hoplon does not require any adapter
Re: [ClojureScript] Using a state machine to design/program UI ?
On Friday, May 15, 2015 at 10:27:46 AM UTC+10, Daniel Kersten wrote: Personally I find that moving state out of components as re-frame's subscriptions and handlers encourage is a desirable trait and would be cautious about reintroducing local state. Keeping my data in one place (and handling updates and queries through a centralised place) has made it a lot easier for me to manage complex data and logic. I've played with javelin in the past and it's a fantastic library. I quite like the idea of using it as a replacement for (or perhaps together with?) re-frames subscriptions (so reagents ratoms, really), but in my opinion reliance on local state is a mistake. I'd like to violently agree with you. :-) State in the one place simplifies so much. The moment you have state in multiple places, and that state needs synchronization, you have a problem. The strategy for solving that problem will involve either (1) things watching other things for changes or (2) things telling other things they have changed. The OO paradigm encourages a lot of distributed, synchronized state, and the The Observer pattern is used to handle it. Those that use component local state with OM, have the same issues as the OO paradigm. Sometimes they use a global bus to achieve synconization (things telling other things that something has changed) which is a similar pattern to various OO framemworks, like PureMVC. In the functional programming space, the movement seems to be towards FRP. Data flows into functions and out again, in something of a pipeline. The structure of those flows is more declarative WRT time. The thing is this: synchronization of state is a pain. Have as little of it going on as you can. Putting all your data in the one place certainly saves you from a certain class of problem -- reintroducing distributed state WILL cause you some grief. I'm not saying never do it, but I am saying there'd want to be a big payoff to warrant the pain. -- Mike -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] Using a state machine to design/program UI ?
Finite state machines are a useful modeling tool, but when implemented in code they can involve a lot of boilerplate and complexity. These days I prefer Rx-like paradigms for sophisticated handling of asynchronous events. e On Wed, May 13, 2015 at 5:54 AM, Khalid Jebbari khalid.jebb...@gmail.com wrote: Hello everyone, As a Javascript web developer, I'm thinking more and more about a good way to design interface so that I don't create a mess. Because I think the current state of the art of web UI development and frameworks is still a big mess. React.js and the CLJS wrapper around them help a bit but not that much I think. My goals are the following : - construct the complete UI logic outside of anything web related, so that it's testable without a browser and usable in other contexts (CLI, back-end, scripts, whatever) - being able to *visualize* the logic without having to read all the code, through diagrams and other means. I've heard in several places that state machines are a good way to handle such cases, since they're inherently event-driven and the web is too. So I start researching. The wikipedia page ( https://en.wikipedia.org/wiki/Finite-state_machine) and the various linked pages are very instructive and indeed explain that a FSM can be used to model UI interaction. I found this 3-parts article series from IBM ( http://www.ibm.com/developerworks/library/wa-finitemach1/index.html) that implements a tooltip using a state machine. Then I found 2 clojure libs that helps design a state machine : reduce-fsm (https://github.com/cdorrat/reduce-fsm) and automat ( https://github.com/ztellman/automat). Both have the *very* nice feature of being able to generate a state diagram from the code, but only automat provides support for CLJS. I think a state machine fits very well with React.js and as so the various CLJS wrappers, since : - in an event-driven state machine, there's a loop listening to events. This event-loop is naturally provided by web browsers - defining strictly and formally the available states helps reduce bugs and maintain the application - the output is always defined by the combination of the input and the current state, which is *exactly* what the render function of React component are about : displaying DOM based only on the state of the component. Since this state is purely data, and CLJ/CLJS are kings when it comes to data, the benefits would be to be able to test the logic a component outside of the DOM and have components that simply emit events (with the associated payload) to the state machines. The various libs in the CLJ/CLJS ecosystem can help greatly : - the aforementioned automat lib to design and visualize a state machine - Prismatic's Schema (https://github.com/Prismatic/schema), Herbert ( https://github.com/miner/herbert) and the likes to formally specify data types/shapes that come in and out of the state machine - test.check to generate lots of input to the state machine and check the output. This can't replace UI testing, but can complement it a lot. Note that Herbert is de facto compatible with test.check - The various React.js wrappers to take this state and simply project it to the DOM. This post is basically a reflection on the subject that I wanted to share and not lose in my mind since I'm new to state machines, and a question to the community : did you already use a state machine to program a web UI ? Successfully ? With which tools ? What do you think of the various libs (aka the stack lol) proposed above ? I know that a simple state machine trivially implemented with no libs at all and may seem often overkill. This post from Spotify ( https://www.shopify.com/technology/3383012-why-developers-should-be-force-fed-state-machines) and this response ( http://www.skorks.com/2011/09/why-developers-never-use-state-machines/) are really interested real world examples of usage (or not) of state machines. Phew ! It was long, I hope I wasn't boring and I'm looking forward to your answers. Let's discuss ! -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at
