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
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
wrote:
> Hello everyone
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/example
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
k
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 wrote:
> And that is why they should be compil
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 interna
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
+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" wrote:
> This is really interesting stuff. I'd looked over Hoplon a year
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, i
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_
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/ni
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 wrote:
> Reagent's create class allows normal
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 wrote:
> No kidding. I have this long blog post germinating in my hea
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 f
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 whicheve
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 wrote:
> Actually, I'm interested in local transitions (cell=) rather than lo
Thanks Brutha! :)
Sent from my iPhone
> On May 14, 2015, at 6:11 PM, Jamie Orchard-Hays 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,
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 a écrit :
>
> Thanks Brutha! :)
>
> Sent from
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 ha
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
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 w
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 some
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 popul
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 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 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
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 wrote:
> I like how you break up the state machines, it has sense in web app. Page 1
> has 2 widgets, pa
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 k
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
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
wrote:
> For local state, I mean state
Thanks, Khalid.
Jamie
On May 20, 2015, at 9:58 AM, Khalid Jebbari 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
>
Yup, well captured.
On Wed, May 20, 2015 at 6:58 AM, Khalid Jebbari
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
>
>
this looks like fun
https://github.com/cdorrat/reduce-fsm
;)
On Wed, May 20, 2015 at 7:26 AM, Marc Fawzi wrote:
> Yup, well captured.
>
> On Wed, May 20, 2015 at 6:58 AM, Khalid Jebbari
> wrote:
>
>> You would want it if you want to inspect/debug/transmit/replay the whole
>> the state of your
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 wrote:
> this looks like fun
>
> https://github.com/cdorrat/reduce-fsm
>
> ;)
>
> On Wed, May 20, 2015 at 7:26 AM, Marc Fawzi wrote:
>
>> Yup, well captured.
>>
>> On
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 wrote:
>
> I mentioned i
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 ar
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 sin
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 a écrit :
>
> Wow, big thread.
> I just want to offer, how I've done a FSM implementa
2015-06-01 17:35 GMT+02:00 Khalid Jebbari :
> 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
Thx ! Will be an interesting read
> Le 1 juin 2015 à 18:00, Herwig Hochleitner a écrit :
>
> 2015-06-01 17:35 GMT+02:00 Khalid Jebbari :
>> 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
Khalid, et al,
Check this out...
http://blog.burntsushi.net/transducers/#finite-state-machines-as-data-structures
On Mon, Jun 1, 2015 at 9:26 AM, Khalid Jebbari
wrote:
> Thx ! Will be an interesting read
>
> Le 1 juin 2015 à 18:00, Herwig Hochleitner a
> écrit :
>
> 2015-06-01 17:35 GMT+02:
41 matches
Mail list logo
