These are chat archives for jdubray/sam

24th
Jul 2017
Janne Siera
@jannesiera
Jul 24 2017 19:08

@jdubray thanks for the clarification on the Model. I'm glad that you confirm that my confusion about Action, Model and State are grounded. These kinds of things might seem obvious to someone familiar with the current front-end frameworks, but for someone like me these explanations really go a long way.

I watched the TLA+ videos and I thought the definitions of Application State and Control State were quite helpful concepts. Like how in OO and Object's state is the 'combination' of all it's properties and how the Object's encapsulation is supposed to make sure it is never in an invalid state. I think that, for me at least, gives a pretty good starting point for what 'state' is supposed to mean. However, this also introduces a lot of confusion to what the 'model' is then.

The confusion gets bigger especially when I think of React as a way to handle state in Views. The functional approach of React was supposed to be a way to 'remove' the state from views as their states get more and more complicated in modern UIs. They appear to be successfull in this with taking a functional approach. But a functional program doesn't NOT have state, programming a game in a purely functional way illustrates this. All the state just lives at the inputs (and outputs) as the data that's fed to it. So it just seems to move the problem, and that's what the industry experienced and where thinks like Redux become necessary.

Janne Siera
@jannesiera
Jul 24 2017 19:27

As for the templating debate, consider this for comparison:

<div>
     ${(value === 0) ? 'This is not just a text, no it's a very long text. Very long text live comfortably in templates. I don't know how this would look in pure Javascript.'
                    : 'I'm trying to illustrate some possible scenarios using 'pseudo' templating syntax, ES6 and Vue.js. Also, I'm trying to illustrate that a small text sample is not always the most realistic one, without exagerating the length of the text either.'}
</div>
<div x-show="{{valueIs0}}">This is not just a text, no it's a very long text. Very long text live comfortably in templates. I don't know how this would look in pure Javascript.</div>
<div x-show="{{valueIs1}}">I'm trying to illustrate some possible scenarios using 'pseudo' templating syntax, ES6 and Vue.js. Also, I'm trying to illustrate that a small text sample is not always the most realistic one, without exagerating the length of the text either.</div>
<div v-if="value === 0">This is not just a text, no it's a very long text. Very long text live comfortably in templates. I don't know how this would look in pure Javascript.</div>
<div v-if="value === 1">I'm trying to illustrate some possible scenarios using 'pseudo' templating syntax, ES6 and Vue.js. Also, I'm trying to illustrate that a small text sample is not always the most realistic one, without exagerating the length of the text either.</div>

I don't know if that makes any difference to you. I know which one I prefer, and I can guess which one our designers would prefer. Anyway, today I asked the question to our design team and I'm curious to see what they'll have to say about it.

Our workflow, or desired workflow, is a bit different that yours. It's very valuable to be able to work along side our designers, and for them to go back to code after we added the interactive parts and change css/html structure. Having them create html/css that we then incorporate in the views is less efficient and can lose us quite some time. This is something that showed very clearly over the last two weeks where we had a very tight deadline but I was, time and time again, required to fix other issues distracting me from the project. The designer I was working with had less strict time requirements and 'saved' the project. We made the deadline just in time and are presenting tomorrow.

Once again, I guess it comes down mostly to preference and what works for the team. I think my personal preference for Web Components also adds to my inclination to have things more html-like and not more javascript-like. There might be some bias at play, but I think something like Vue (where we have the option for both) would probably be a desirable choice for our team.

Antanas A.
@antanas-arvasevicius
Jul 24 2017 19:41
it's html-like + something else
"x-show" "v-if"
god knows how much logic exists in these templates
so designer must learn that template "language" at first
that template language must have its own tooling: IDE support, syntax checker/linter, debugger?
manual, documentation
I think there is also multiple versions of it, so designers must know backward compatibility tricks etc.
For example in PHP there was a pros of these template langauges as they allows "safe code" execution
Antanas A.
@antanas-arvasevicius
Jul 24 2017 19:46
but in javascript you can just run your "js template" just in a new VM ( https://nodejs.org/api/vm.html ) if safety is necessary
Within ES6 / ES7 these templates can look nice, and also we can generate template in future, e.g. return Promise<string>
cases would be: translations are loaded from database lazily, or seo URL is generated from remote seo service.
const template = async () => `<a href="{await seoService.getUrl('someUrl')}">news</a>`
how would you do that with template "language"?
Antanas A.
@antanas-arvasevicius
Jul 24 2017 19:54
why would we need some HTML like language when there is a general purpose JSX / TSX which allows easily generate AST's which later can be interpreted?
Jean-Jacques Dubray
@jdubray
Jul 24 2017 20:17
@antanas-arvasevicius :+1:

@jannesiera Glad I could clarify a bit. React started on the wrong foot with props and state, with complex componenet lifecycles and no real good place to weave API calls. Then they slowly went functional.
As for me, I don't understand why everyone is trying to ignore "mutations", you can't solve a problem by pretending it does not exist.

So it just seems to move the problem

I am not certain redux solves it that much, putting a function on top of spaghetti code that can't even call an API is not going to help you much. The problem with Games is perhaps the scale of the application state. I'd be surprised if Redux can help you there.
Jean-Jacques Dubray
@jdubray
Jul 24 2017 20:23
@antanas-arvasevicius I would not wire an API call to the "view" :-)
Janne Siera
@jannesiera
Jul 24 2017 21:10
@jdubray what do you understand exactly by 'mutations'? And which is the problem that people are ignoring? Because this all sounds very abstract to me.
Jean-Jacques Dubray
@jdubray
Jul 24 2017 22:07
@jannesiera The fundamental problem is that we equate assignment with mutation
of course you need assignments, but not all assignments are mutation, at least should not be.
SAM is trying to reduce mutation to a critical section of your code, that is as small as possible (unlike a Redux reducer)
SAM is achieving that by:
a) creating a proposal to mutate the application state, so you know exactly what you want to achieve (that's the role of the action)
b) computing the state representation once the mutation is complete
When you conflate proposal (the new values of the application state), the mutation and the state representation you create spaghetti code (not to forget NAP). That code is hard to debug and maintain. There is no reason it should be that way.
When you create a proposal, you have not mutated anything, when you compute the state representation you are not mutating anything (just adding new computed values).
Actions -> Functional Programming
Model -> Object Oriented Programming
State -> Reactive Programming
Jean-Jacques Dubray
@jdubray
Jul 24 2017 22:15
How can you pretend you can achieve a better mutation with immutability? (Redux/Elm)
In other words, Functions are good at creating proposals (an Action is a pure function)
Objects are good at encapsulating (application state), the Model is an Object, with a single method (closure ok)
Reactive programming is good at computing new values in reaction to changes in other values (dependencies between properties)