These are chat archives for jdubray/sam

17th
Aug 2016
Jean-Jacques Dubray
@jdubray
Aug 17 2016 00:43
I was wondering if people discussing topics on this list would be interested in switching to ryver. The main advantage is that they have "posts", so someone could "post" a question and we could discuss the answer(s).
Jean-Jacques Dubray
@jdubray
Aug 17 2016 04:48
@srconklin I have started to work on your sample
Fred Daoud
@foxdonut
Aug 17 2016 05:23
@jdubray I'd be willing to try it.
Jean-Jacques Dubray
@jdubray
Aug 17 2016 05:23
@srconklin I think I got it to work, there are still a few wrinkles to iron out to get the full sample working, but the focus seems to be working fine
The key was to pass the current input value (I probably should have given you more details)
If you don't update the value in the model it returns to display the original value, otherwise I didn't change anything to focus code I had shared
@foxdonut it's pretty late in Montreal!
Fred Daoud
@foxdonut
Aug 17 2016 05:27
@jdubray indeed it is 1:26am, just got up for a bit because I couldn't sleep...
Edward Mulraney
@edmulraney
Aug 17 2016 08:46
@jdubray would stackoverflow be a better medium than ryver? ryver doesnt seem to offer much over slack
stackoverflow gets coverage
Jean-Jacques Dubray
@jdubray
Aug 17 2016 09:36
I can give it a try
Jean-Jacques Dubray
@jdubray
Aug 17 2016 10:12
I have 9 keybase.io invitations if anyone is interested
Just for the record, it just looks like one of these NSA funded app, but if not, the idea is pretty cool
Edward Mulraney
@edmulraney
Aug 17 2016 13:06
@jdubray nice, yeah i'd be interested JJ
Scott Conklin
@srconklin
Aug 17 2016 13:41
@jdubray thanks for the work on the sample. Unfortunately I don't see any difference at all. The issue remains. How does of the onInput event help in this case? Don't we need the onFocus event to fire an action to set the focus somehow? Do you see what I mean? just like in mine, in your sample I can type something into the textarea and then when you either click on one of the textboxes or the link below it; nothing happens. You have to click a second time for it to "operate".
Jean-Jacques Dubray
@jdubray
Aug 17 2016 14:17
@srconklin I am not sure I understand what you are trying to do. What the sample is doing is for every character it executes a reactive loop (action->model->state->view) and use nap() to refocus once the view is redrawn. That allows you to make the UX richer changing different parts of the UI without waiting for the user to "submit" a form. You can of course do validation, autocomplete, ... as part of the action and/or model.
to answer your question, no, I don't see why you need "onFocus", though it would work just as well if you needed to do something when the user clicks on the field.
@edmulraney what is your twitter handle?
Edward Mulraney
@edmulraney
Aug 17 2016 14:22
@edwardmulraney
Valerio Versace
@vforvalerio87
Aug 17 2016 14:29
@jdubray hi thanks again for the sample; we are using SAM for a contact form and we came up with a problem: in the xhr request in your example you log the error to the console. In our case, we need to use it in the flow of the application (success: render the "Sent" view; error: render an "Error" view). We considered two options: either doing "state.render(model)" in the callback function or using the callback function to call an action from inside the model. Which is the recommended course of action? Is there another option that we are not considering? thanks
@jdubray we can give you a link to the code if you want
Jean-Jacques Dubray
@jdubray
Aug 17 2016 14:34
sure, but you can present an error to the model just as well, there is no conceptual barrier to it. If the error happens in the model, you can update the model accordingly and render the state representation.
Valerio Versace
@vforvalerio87
Aug 17 2016 14:38

@jdubray so we do the POST request inside the mode;
then both in the success callback and the error callback we should do (example):
model.sent = true ; (or model.error = true)
state.render(model) ;

is that correct?

Jean-Jacques Dubray
@jdubray
Aug 17 2016 14:42
yes correct
Valerio Versace
@vforvalerio87
Aug 17 2016 14:43
cool, thanks!
Jean-Jacques Dubray
@jdubray
Aug 17 2016 14:43
you may decide that the render can only happen synchronously to the API call, so you need to use a promise
In that case the UX would be blocking
it's that simple, that the power of functional HTML (V = f(M))
Valerio Versace
@vforvalerio87
Aug 17 2016 14:45
in that case we'd probably rather send an action from the model, but I feel like calling the render function from the callback would be more appropriate
anyway the contact form made with SAM works correctly so we are going to keep it in the live website as soon as it goes in production
Jean-Jacques Dubray
@jdubray
Aug 17 2016 14:49
fantastic!! Please send me the link, I'll add it to the sam.js.org web site
@edmulraney you are not following me, so I cannot send you the link
Valerio Versace
@vforvalerio87
Aug 17 2016 14:56
@jdubray sure I'll send the links as soon as the sites are up (couple of days); thanks again
Jean-Jacques Dubray
@jdubray
Aug 17 2016 14:56
no worries, any time!
@vforvalerio87 if you are building a form in vanilla.js do not forget to escape and validate your inputs
Valerio Versace
@vforvalerio87
Aug 17 2016 14:59
@jdubray yep we are handling xss and csrf right now
Edward Mulraney
@edmulraney
Aug 17 2016 15:20
@jdubray followed!
Jean-Jacques Dubray
@jdubray
Aug 17 2016 15:29
@edmulraney I sent it to gitter actually, did you get it?
Edward Mulraney
@edmulraney
Aug 17 2016 15:30
ah yes - thank you
Jeff Barczewski
@jeffbski
Aug 17 2016 16:14
@edmulraney @jdubray ryver is pretty interesting to me versus slack, it allows you to take conversations that start in the chat and promote them to discussions (like in a forum) which is far better for long term benefit than trying to find stuff in a mixed chat log. You select the responses that belong in the discussion and click a menu to promote it to a discussion. Seems like a killer feature to me.
Jean-Jacques Dubray
@jdubray
Aug 17 2016 16:15
yes, that looked interesting to me as well
Scott Conklin
@srconklin
Aug 17 2016 16:31

@jdubray What I am trying to do is fix the symptom that I describe above, namely:

I can type something into the textarea and then when you either click on one of the textboxes or the link below it; nothing happens. You have to click a second time for it to "operate".

@jdubray 1) type some characters in the textarea, 2) using your mouse, click the link 'make another entry'
does it also not immediately do anything for you? Does it require a second click to work?
All of this is because the onblur of the textbox is firing while one tries to click the link which is in the middle of being re-rendered.
I believe this would not happen if were using a dom diff lib instead of just plain HTML/JS to rewrite the whole view, am i correct?
but would rather not use one.
devin ivy
@devinivy
Aug 17 2016 16:38
honestly, i think using a simple dom library goes a long way and handles a lot of edge-cases. replacing portions of your dom all the time just tends to generate problems in lots of real-world scenarios.
if you want a relatively simple step up, try snabbdom.
Scott Conklin
@srconklin
Aug 17 2016 16:41
@devinivy I am starting to realize that... I had a similar question a long time ago about trying to get a slider to update in realttime the value of the slider into a span just above the slider and could not get it work easily... using s dom diff solved it.... @jdubray showed me a way that required a lot more intervention than i cared to manage... with a sliding vs ready state that only re-rendered what was necessary.
devin ivy
@devinivy
Aug 17 2016 16:41
i remember that!
if you want to use something that is not virtual dom, check out incremental-dom by google.
it diffs dom in-place. it feels a little simpler in some ways.
Scott Conklin
@srconklin
Aug 17 2016 16:42
@devinivy thanks i will...
devin ivy
@devinivy
Aug 17 2016 16:42
incremental-dom is very low-level. i think there's a library built on top of it that's more usable, but i forget its name.
Scott Conklin
@srconklin
Aug 17 2016 16:44
I have a fiddle somewhere with the slider sample that uses snabbom which was not so bad.. sort of intuitive; I was just holding out for the hope of writing my views in just HTML which was my preference, but I suppose i need to adapt.
devin ivy
@devinivy
Aug 17 2016 16:45
oh! well, there's always HTML <template> and web components!
that's my personal preference. when i get to choose what i use to make web-stuff, i use polymer.
i fully agree w/ you though– when HTML can be used it's gr8 :)
Scott Conklin
@srconklin
Aug 17 2016 16:46
@devinivy . thanks I have seen polymer but never looked at it.. maybe I should revisit it in more depth.
devin ivy
@devinivy
Aug 17 2016 16:48
although the framework is useful, you might find that subsets of polymer are more your style. it comes in mini, micro, and standard (the whole polymer framework). for example, you might just want to use <dom-bind>.
will make more sense after a google.
Scott Conklin
@srconklin
Aug 17 2016 16:48
@devinivy do you ever use web components?
devin ivy
@devinivy
Aug 17 2016 16:52
yes! i love working with them.
Scott Conklin
@srconklin
Aug 17 2016 16:53
would web components be a complete solution for managing views without the need for a dom library? or am I thinking about it incorrectly?
devin ivy
@devinivy
Aug 17 2016 16:56
yes, it could be. polymer provides all the sugar on top of web components to make it ergonomic to author views.
Scott Conklin
@srconklin
Aug 17 2016 16:56
@devinivy thanks. I will def. give that a look
devin ivy
@devinivy
Aug 17 2016 16:57
welcome! will be interested to hear your thoughts after you take a look.
Jean-Jacques Dubray
@jdubray
Aug 17 2016 17:54
@srconklin "showed me a way that required a lot more intervention than i cared to manage..." really? an <output> tag is too much for you?
We need to clean up the "edge cases" in HTML. Why should we keep fixing broken things with yet more boilerplate? HTML has a clear evolution path towards functional HTML and away from DOM manipulation.
devin ivy
@devinivy
Aug 17 2016 18:10
@jdubray why mutate state but not the dom?
Scott Conklin
@srconklin
Aug 17 2016 18:11
@jdubray I am sorry. I don't know what you mean. what is an <output> tag? The case I was describing to @devinivy was the old slider example from long ago that required management of a separate state for when the slider was sliding and when it was being rendered for the first time. An alternative example that used snabdom avoided that extra management and decluttered the model and state machine.
devin ivy
@devinivy
Aug 17 2016 18:12
the dom has problems (bloat from years of standards), but i don't include this as one of them. when you remove an input then add an input the dom shouldn't necessarily understand that as a replacement simply so that it can maintain focus on the element.
you have to add some more code so that the input's value is updated instead. simple as that! i realize it undermines willy nilly setting of innerHTML.
and i similarly love functional HTML. but this doesn't mean the DOM is broken because it doesn't diff-and-patch without a little extra work.
element references are important!
Jean-Jacques Dubray
@jdubray
Aug 17 2016 18:17
blob
@srconklin when people spend a good amount of their time building what you asked, you, perhaps would want to take a look at it, rather than bashing randomly their work
Scott Conklin
@srconklin
Aug 17 2016 18:25
@jdubray I think we are all miscommunicating...
1) I am not bashing anyone's work. I am only try to learn best practices for solving issues that arise when trying to implement something in the SAM pattern.
you have been very helpful by providing examples whenever I have had questions.
2) the snippet you pasted above has nothing to do with anything we are talking about now... I did look at that way back when and learned from it.
3 ) the most recent issue that I am having (and still trying to solve without using a dom lib) is the one you drafted for me just yesterday , where the issue still remains.
I believe I have not communicated what the issue is when i talk about focus... (see my explanation above)
https://github.com/jdubray/sam-samples/tree/master/vanilla-focus-fields
4) the slider one was something else you helped me solve that I was discussing with @devinivy that was more easliy solved (IMO) by using snabdom than using extra coding to manage what needed to be rendered. It really was a side conversation to everything else
devin ivy
@devinivy
Aug 17 2016 18:35
SAM works great with snabbdom or vanilla innerHTMLing.
Jeff Barczewski
@jeffbski
Aug 17 2016 18:39
@devinivy I came across https://github.com/jcoreio/redux-plugins-immutable and https://github.com/jcoreio/redux-utils The first is a plugin system for redux which allows you to dynamically load component, reducer, routes, middleware but it requires immutablejs (probably could be ported to not need it pretty easily, I think they just used it for convenience). Second was a few utilities for doing hot pluggable middleware and composing reducers, etc. So those might be some projects to get inspiration from when you are building yours.
devin ivy
@devinivy
Aug 17 2016 18:40
:pray: thx!
Scott Conklin
@srconklin
Aug 17 2016 18:42

@devinivy then maybe you can take a look at https://jsfiddle.net/sconklin/qfz27mtm/ and tell me how to best address the issue seen by
1) typing into the textarea
2) and then clicking the link 'make another entry'
you will see that it does not work; one must click again.
This is because the onblur is firing while re-rendering the view...

the solution is somewhere in setting the focus via an onFocus action triggered somewhere, nap(), setimeout or some other combination of a all.....

or maybe the use of onblur to update the model is a bad approach and there is more clever solution
devin ivy
@devinivy
Aug 17 2016 18:44
i don't know the easiest way to deal with that. i think @jdubray knows an efficient way. i prefer to manipulate the dom rather than reset innerHTML.
Scott Conklin
@srconklin
Aug 17 2016 18:44
@devinivy i see thanks... Now i understand your comments above.
Jean-Jacques Dubray
@jdubray
Aug 17 2016 20:26

@srconklin the solution is simply to delay the save action, assuming that's logically possible to reorder the user events

actions.save = function(data) {
      // var notes = document.getElementById("notes" + data).value
        var formData = {
            notes: document.getElementById("notes" + data).value,
            timeIn: document.getElementById("timeIn" + data).value,
            timeOut: document.getElementById("timeOut" + data).value
        }

        setTimeout(function() {  
            model.present({
                saveitemID: data,
                item: formData
            });
            },200) ;
      return false;
    }

Alternatively, you can also handle it in the nap() function to execute the save action

Jean-Jacques Dubray
@jdubray
Aug 17 2016 20:45
the setTimeout method is a cheap form of nap(), stateless if you will.
Scott Conklin
@srconklin
Aug 17 2016 20:46
@jdubray ah! so simple... I will give that a try shortly. Thanks
@jdubray Also... the fiddle was built form an existing small app where jquery was used to manipulate the DOM.... (callback hell!) .. Given a clean slate, I would approach the design in much the same the vanilla JS TODO example does. I like one set of form fields where edit mode fills the elements with the correct values. BUT.. the goal was to test out SAM by using the principles learned here and NOT change anything in the UI
Jean-Jacques Dubray
@jdubray
Aug 17 2016 20:52
IMHO, save is logically a next-action, you get an event (add record), attaching save to onBlur is not the best choice. This is, again IMHO, the problem when you do not follow SAM:
event->action->model->state->view  
                        |--> nap()
Scott Conklin
@srconklin
Aug 17 2016 20:54

attaching save to onBlur is not the best choice.

that is the kind of input i wanted to hear, but how does this violate SAM? onblur is an event that fires an action that updates the model that changes the state that updates the view

Jean-Jacques Dubray
@jdubray
Aug 17 2016 20:54
there is no reason to use onBlur
well, in reality, the event was add record, not onBlur, you need to process that event first, it happens that, in the new application state, there is an automatic action, "save"
Scott Conklin
@srconklin
Aug 17 2016 20:55
Save mapped to onBlur is meant to save the user's input should you click the link to add another row(which if I did not have the users input is lost)
Jean-Jacques Dubray
@jdubray
Aug 17 2016 20:57
I know, but again, the logical way to represent it is that the new application state triggers an automatic action. It does not mean that because you can you should do it.
I see your point, nap() would not have the user input
Scott Conklin
@srconklin
Aug 17 2016 20:59
@jdubray yes and maybe you were trying to tell me earlier that onINput was meant to save the users's keystrokes as they type?
this would be the way a React component has you do it, no?
Jean-Jacques Dubray
@jdubray
Aug 17 2016 21:00
that's another way to do it. You just cannot process two events "concurrently", that is forbidden in SAM / TLA+
Scott Conklin
@srconklin
Aug 17 2016 21:02
@jdubray so onBLur is a bad approach. you would recommend saving the user's input via an onInput event ; making the onblur unnecessary which in turn would solve the issue of the link not working when leaving textarea ?
Jean-Jacques Dubray
@jdubray
Aug 17 2016 21:03
The absolute cleanest way would be to use a dispatcher which handles this kind of situation and queue the second event (add record) to be executed in nap()
Scott Conklin
@srconklin
Aug 17 2016 21:04
hmm, ok
Jean-Jacques Dubray
@jdubray
Aug 17 2016 21:04
I'd say, I'd try to avoid situations where two events are triggered "concurrently" (each competing to display something )
Scott Conklin
@srconklin
Aug 17 2016 21:04
yes i understand that point
devin ivy
@devinivy
Aug 17 2016 21:04
in this case, which two events are competing?
Jean-Jacques Dubray
@jdubray
Aug 17 2016 21:05
onBlur and click (save and add record)
When you click on the link the browser triggers onBlur??
Scott Conklin
@srconklin
Aug 17 2016 21:06
yes
currently yes
and clicking the link obviously fires the addRow action
Jean-Jacques Dubray
@jdubray
Aug 17 2016 21:07
that's a problem, this is the source of all problems in front-end architecture, we are trying to execute a second action before reaching a stable application state.
It looks as if though that the browser reorders the events...
otherwise, onBlur should execute second, after the add record action completes
Scott Conklin
@srconklin
Aug 17 2016 21:08
Yes, but the best practice solution eludes me.... I think you are saying best solution is to dispatch and queue the second
OR save user input on keyUP which deprecates need for onblur
Jean-Jacques Dubray
@jdubray
Aug 17 2016 21:11
if the browser is responsible for the incorrect ordering, then the dispatcher should be able to reorder them properly. I am not sure why the events seem to fire in the reverse order (onBlur first and click second).
the browser is not perfect...
Scott Conklin
@srconklin
Aug 17 2016 21:14

I am not sure why the events seem to fire in the reverse order (onBlur first and click second).

why would you say this is the incorrect order... I leave the field before I click the link (well technically) ..doesn't this make sense? seems like the right order to me.

Jean-Jacques Dubray
@jdubray
Aug 17 2016 21:15
yes, then it is the browser which is dropping the ball and not passing the second event properly. I would expect the browser to queue the events, and not have to add a dispatcher.
The SAM implementation is pretty straightforward (single threaded), so there is no reason for the SAM code to not process the events correctly when presented properly (in any order).
Scott Conklin
@srconklin
Aug 17 2016 21:17
@jdubray well doesn't that have to do with the fact the dom is in the middle of being destroyed and created by innerHTML() inside of the display function.. this is the rendering in progress problem we are talking about, no?
Jean-Jacques Dubray
@jdubray
Aug 17 2016 21:18
that being said, I don't think this is true because you systematically have to click twice, I do believe, the browser triggers onBlur when you click on the link
I just tested it and onBlur does not execute when you leave the text area, only when you click on the link ...
Scott Conklin
@srconklin
Aug 17 2016 21:21
it must! otherwise ; if i add some text, click on the canvas and then click the link, I would loose my data entry
Jean-Jacques Dubray
@jdubray
Aug 17 2016 21:21
so, yet, it looks like the browser removes the event because you redisplay it, but as I mentioned earlier, it is because the browser reorders the events.
the logical order is click then onBlur
it is onclick that triggered onBlur.
that precisely the problems that appear when someone tampers with the underlying state machine.
Scott Conklin
@srconklin
Aug 17 2016 21:24

hmm.

the logical order is click then onBlur
I always thought it was the other way around

Jean-Jacques Dubray
@jdubray
Aug 17 2016 21:24
That's precisely why you need to use a structure like SAM, to reason clearly about event / state.
Scott Conklin
@srconklin
Aug 17 2016 21:25
so the takeway for this example is not use onBlur and update the model for edits in another waty
Jean-Jacques Dubray
@jdubray
Aug 17 2016 21:25
you may think so, but it not until you click that onBlur executes. So, somewhere someone has switched the direction of time, you can't do that...
Scott Conklin
@srconklin
Aug 17 2016 21:26
hmm You are right.. I thought clicking anywhere on the page also fired the onblur.. does not appear to be true
Jean-Jacques Dubray
@jdubray
Aug 17 2016 21:26
I'd say the take away it to always be aware of the logical sequence of action, event -> new state -> nap()
the event is clearly onClick, not onBlur
Yes, it does, if you click any where it fires it
then the link works fine
Scott Conklin
@srconklin
Aug 17 2016 21:27
yes, you are right
Jean-Jacques Dubray
@jdubray
Aug 17 2016 21:28
clearly the sequence of event produced by the browser is illogical
I would call it a bug
Scott Conklin
@srconklin
Aug 17 2016 21:28
chrome?
Jean-Jacques Dubray
@jdubray
Aug 17 2016 21:28
maybe
no, they all have the same behavior
Jean-Jacques Dubray
@jdubray
Aug 17 2016 21:35
It is not surprising that I corrected the problem by reordering the events (in the proper order).
You have to convince yourself that events / state mutations sequences are not arbitrary, once an event is triggered, it has to mutate state before another once can be processed. That's probably the biggest lesson to learn from TLA+, (temporal logic of Actions)...
you just cannot tamper with it.
Scott Conklin
@srconklin
Aug 17 2016 21:38

It is not surprising that I corrected the problem by reordering the events (in the proper order).

you did this where? in the sample?

Jean-Jacques Dubray
@jdubray
Aug 17 2016 21:38
setTimeout
Scott Conklin
@srconklin
Aug 17 2016 21:38
ah!
Jean-Jacques Dubray
@jdubray
Aug 17 2016 21:39
here:
setTimeout(function() {  
            model.present({
                saveitemID: data,
                item: formData
            });
            },200) ;
Scott Conklin
@srconklin
Aug 17 2016 21:39
so setTimeout is also an acceptable solution .. or better to avoid onBlur and fire the save event in another way?
Jean-Jacques Dubray
@jdubray
Aug 17 2016 21:40
yes, I'd say it's better to avoid these edge cases, it feels a bit iffy to use a setTimeout
I'd say there is a double bug in the browser:
1/ sequence is wrong
2/ dropping an event because you render feels wrong, the event should be decoupled from the DOM element, once issued, it should be remain in the queue regardless
devin ivy
@devinivy
Aug 17 2016 21:45
how do you know the order is wrong? you lose focus on mouse down. a click completes after mouse down then mouse up.
you can see the focus outlines when you click down on each input. it's natural to focus as soon as you mouse down.
i really think that the limiting factor is trying to recreate your UI from scratch when really all you are performing is a mutation of the UI– a simple one, at that.
Jean-Jacques Dubray
@jdubray
Aug 17 2016 21:55
from a "temporal logic of action" perspective, the order is wrong, the first event must mutate the application state before the second one is processed, period, any tampering is subject to inextricable glitches. That is the problem.
you have to understand that the sequence event -> application state is not arbitrary
you can decide to do whatever you want, and we see it constantly, but that's at your own risk.
devin ivy
@devinivy
Aug 17 2016 23:07
@jdubray i still don't understand the bug. what application state is the browser not processing between mousedown, focus, mouseup, and click? are you talking about the SAM app or the browser bug? i'm just saying i don't see how it's a browser bug because blur should come before click.
Jean-Jacques Dubray
@jdubray
Aug 17 2016 23:12
it's a conceptual bug, an event must lead to application state mutation, before a new event is processed or compose with another one and lead again to a single application state mutation, you cannot arbitrarily invoke an onBlur event from an onClick event, that is "forbidden" conceptually. Again that is the problem, we cannot arbitrarily take these decision. You may believe, you are full decision power, but it is simply not the semantics of a state machine.
There is a flow to application state mutation and that flow cannot be changed or tampered with.
On occasion, you might find "safe" optimization, or on the contrary generate glitches like this one.
devin ivy
@devinivy
Aug 17 2016 23:15
but whose state machine are you referring to?
the browser's?
Jean-Jacques Dubray
@jdubray
Aug 17 2016 23:22
the application state, the browser has it's own, from a business logic perspective the contract is event -> new application state -> new state representation
devin ivy
@devinivy
Aug 17 2016 23:24
i'm still struggling to understand this as a browser bug :/ it seems consistent to me and that the example above just isn't working well with the DOM's API to achieve what it's trying to do.
to be fair, i also think it's trying to do a somewhat hard thing.
Jean-Jacques Dubray
@jdubray
Aug 17 2016 23:34
The semantics of the state machine are unequivocal, the bug is that if the browser was following them event1 / mutation1 / event2 / mutation2, there would be no bug. The bug comes from the browser sequence, Event 1 / Event 2 / mutation 2 / mutation 1 sequence. That sequence is forbidden.
You can say no big deal, why is it forbidden, but it is. Staging the application state 2 before the application state 1 is what causes the problem, nothing else.
It is the equivalent of saying, I can stop a car before it starts.
devin ivy
@devinivy
Aug 17 2016 23:36
but those events are browser events and those mutations are SAM-app mutations. i would say that the SAM app needs to use the browser events differently when calling actions, and that the SAM app is the one trying to "stop the car before it starts".
(by calling and allowing actions in a problematic order)
Jean-Jacques Dubray
@jdubray
Aug 17 2016 23:37
look, there is not much I can add, this is state machine 101
devin ivy
@devinivy
Aug 17 2016 23:38
i'm familiar with state machines, but i think there's confusion here over the browser's events and the SAM app's actions.
i'm still referring to the SAM app many chats above ^^ :D
Jean-Jacques Dubray
@jdubray
Aug 17 2016 23:39
again, there is not much more I can, apologies for not being able to close the discussion.
devin ivy
@devinivy
Aug 17 2016 23:40
cheers! it's okay! it's hard to speak precisely over gitter compared to a conversation in person!