These are chat archives for jdubray/sam

30th
Jul 2017
Jean-Jacques Dubray
@jdubray
Jul 30 2017 01:38
@jannesiera yes exactly, as soon as you event loop branches to an async call, another action could be executed and present a proposal prior to the model. The SAM-SAFE library (as pointed out by Daniel) tracks the "step" in which a proposal is made and could be rejected if it is out-of-step.
To minimize concurrency issues, you may want to use an { add: xxx } proposal rather than { newValue: yyyy } proposal.
What's interesting about JavaScript concurrency is that you can implement a generic "cancel" mechanism when you track the step in which a proposal is made (e.g. an older proposal is ignored by the model which already processed a newer proposal). Alternatively, you can also make the model responsible for tracking cancel requests and ignore the proposal of an action which made an API call.
Janne Siera
@jannesiera
Jul 30 2017 10:57
Could anyone take a look at this for me? I'm wondering whether I'm on the right track. https://gist.github.com/jannesiera/754f87ae879d9216a78aceb85a8d7010
Slađan Ristić
@sladiri
Jul 30 2017 12:26
since nothing can happen while these listener functions are running, this should work fine. If they did asynchronous calls, then you would have a problem.
Janne Siera
@jannesiera
Jul 30 2017 12:55
@sladiri howcome?
(you did open the link and looked at the whole example right?)
Slađan Ristić
@sladiri
Jul 30 2017 13:27
@jannesiera I just looked at those two event listeners you showed here. What do you mean by how come?
Janne Siera
@jannesiera
Jul 30 2017 13:41
@sladiri open the link. Gitter is showing the first 29 lines of a 300 line document.

// The code here starts with a 'basic' implementation of one would go about this and
// then proceeds to try and factor the event handlers to a more reusable and maintainable structure.

I'm only addressing concurrency issues in the last step.

Jean-Jacques Dubray
@jdubray
Jul 30 2017 13:55
@jannesiera from what I can tell everything is synchronous (?), so you should not run into any concurrency issue. If you change your actions to include a random timeout (that would make the game more fun!), that's when concurrency issues would show up. Am I missing something?
Otherwise, this is a valid SAM implementation (though the State function is missing, and hence nap()). The "state representation" is different from the application state (managed by the model).
Slađan Ristić
@sladiri
Jul 30 2017 14:18
That is what I thought too. If you changed the value inside a setTimeout, you would see problems.
Janne Siera
@jannesiera
Jul 30 2017 14:28

@jdubray in the last iteration I make a change from proposing values to proposing a command. Wouldn't this address the concurrency issue?

I realize the state representation is missing, but good to know I'm on the right track. I took your comment of SAM is about factoring event handlers and see if I could find a valid use case for it. It's only when I added a validation rule that the penny dropped for me.

I'll look into state representation and nap now. I feel like I'm starting to understand how SAM works (after all it's not that complicated) but I'm still struggling to see how it could actually help me and to find good use cases for that.

Like I mentioned before, if SAM could help me with decoupling from a front-end framework that would already be a massive feat in and of itself. Now, it's a matter of validating that promise.

--

As a mostly unrelated question: What are your personal thoughts about most of the modern front-end frameworks like Angular, React, Vue, ... ? In general, whenever I start looking into one it just always seems over-engineered in one way or the other and I always feel like I'm missing a key insight into why they are engineered in such a way.

Jean-Jacques Dubray
@jdubray
Jul 30 2017 14:31
yes, absolutely! that's how I would do it.
I can assure you that in all the code I write the business logic is 100% decoupled from the view. The only interface between the two are props and events, and of course the SAM loop has no knowledge whatsoever about what the view does with the props and how the events are generated and wired to actions.
Jean-Jacques Dubray
@jdubray
Jul 30 2017 14:37

it just always seems over-engineered

yes, that's pretty much where I am. For instance Angular is "type-checking" everything (so I use : any most of the time :-)) but it can't catch circular dependencies that throw Webpack in a vortex. This is ludicrous. Same with React, which in the end was just V = f(M).

So I use ES6. I don't believe in Web Frameworks. They make no sense at all.
When you look at Angular or React, they are clearly engineered on the fly:
a/ because Angular changes all the time its APIs
b/ React keeps adding libraries right and left
I don't believe that the people designing these framework know what they are doing. They are paid/incentivised to create a framework.
The framework will sprawl as long as they get paid to do so.
Jean-Jacques Dubray
@jdubray
Jul 30 2017 14:56
My theory about building a sprawling framework like React or Angular, is you have to start with a programming model that is as broken as possible, then you keep adding crutches to allow people to walk in such a broken way.
Janne Siera
@jannesiera
Jul 30 2017 14:57

@jdubray any specific reason you don't use type checking? We are planning to use something like Typescipt or Flow either way, especially since most of our developers are used to C# and are VERY uncomfortable with no typing. I'm a bit more comfortabel with Javascript myself, but still would prefer typing to make Interfaces and API's explicit.

Have you looked at Polymer and/or Web Components?
And the Aurelia framework? That seems to be quite modular and tries not to get in your way too much.
An what about Vue? you say it is pretty close to the SAM pattern. It also promises a more decoupled view layer.

Jean-Jacques Dubray
@jdubray
Jul 30 2017 15:17
Here is a great illustration of Web Frameworks
image.png
I am a message/service oriented guy. Classes always get in the way, for nearly zero value because all the important validations rules are not structural.
People like the comfort of a class because of initialization (uninitialized/undefined variables), not because of type checking. That's a myth.
I use a simple trick. I use a 20 line library that makes sures all my variables are initialized properly.
Jean-Jacques Dubray
@jdubray
Jul 30 2017 15:22
For instance I use the A(), O(), S(), I() function like this:
function f({myArray, myObject, myString, myInt}) {
     myArray = A(myArray)
     myObject = O(myObject)
     ...
}
such that I don't worry about uninitialized variables in my code.
I get it, if you don't use such a trick, JavaScript is a real pain
you could also used default values like f(myArray = A(), myObject = O(), myString = S(), myInt = I()
but I like the first approach better because I can check that the function parameter is of the right type, when not, I just substitute the value for the right type, such that my code can run (minimizing runtime errors is important).
I use these functions throughout the code like: let val = O(myArray[5]).value
I never feel like I need a class for that.
Jean-Jacques Dubray
@jdubray
Jul 30 2017 15:31
I am a no framework guy. I only use Angular for enterprise customers/IT, it's programming model is straightforward for enterprise customers.
Janne Siera
@jannesiera
Jul 30 2017 16:42
@jdubray good to know. Thanks for your input!
Jean-Jacques Dubray
@jdubray
Jul 30 2017 17:45

A simple example of framework insanity:

The params are now immutable so you have to set them when you initiate the new HttpParams.

 const params = new HttpParams()
        .set('personId', personId);

why? who in the world could think of such an API in 2017? and that's already the nth version of the Angular's HttpClient!

Nivani
@Nivani
Jul 30 2017 18:24
I like type-safety because I find that it makes it easier to understand code by looking at it or by looking at function signatures.
I tend to use a lot of interface in typescript, not class
It's nice that you can:
interface Foo {
  abc: number;
  def: string;
}

const msg: Foo = {
  abc: "5",  // Error because type mismatch
  defg: "some string" // Error because property does not exist in Foo
};
Nivani
@Nivani
Jul 30 2017 18:29
I agree with your opinion on the HttpParams immutability though, I don't see why it should be immutable
Jean-Jacques Dubray
@jdubray
Jul 30 2017 19:34
I understand why people like it, but just like everything in our industry we should evaluate the ultimate value in terms of productivity, maintenance, clarity...
We have build a lot of Cargo Cults in the past few decades
Antanas A.
@antanas-arvasevicius
Jul 30 2017 20:53
TypeScript is not about classes at all, it's main goals: 1) support latest ES standards and allow to transpile it down as idiomaticly as poasible
2) create a type system which would allow express all available javascript patterns for API
3) make powerful type interrencing that you need to write types explicitly less
and type system is gradually typing system if it cant infer type then type is any, but this can be prohibited by -noImplicitAny compiler flag
Antanas A.
@antanas-arvasevicius
Jul 30 2017 20:59
I'm with typescript since first beta release and never go back :)
We have more than 170k lines of code in typescript
4dev over 3.5years
It compiles in about 11seconds now, and I rarely have seen a such maintainable project on such scala and javascript
We have client zone portal with javascript and developers regrets that we didn't start it with typescript (thought it will be small site)
Antanas A.
@antanas-arvasevicius
Jul 30 2017 21:04
As of TS 2.4 version with allowJs checkJs flags ts can be used on js only projects and get tranapiler+lintet for free
Just npm install tsc -g and tsc init :)
Jean-Jacques Dubray
@jdubray
Jul 30 2017 22:25
@antanas-arvasevicius please don't take this negatively, but 170k / (4 x 48 x 3.5) is 253 LOC / week / developer is exactly the average productivity of a java developer (250 LOC in production per week). I am not trying to say your team is average, it's very hard to go beyond the 250 LOC barrier even for the most talented developers, this is more a reflection on the technology itself. It doesn't move the needle. Again, I understand why people like it, I don't dislike it, for once they didn't butcher JavaScript.
Jean-Jacques Dubray
@jdubray
Jul 30 2017 22:57
I don't claim I have experience in all possible technologies, but for instance SpringBoot which has become extremely verbose in the past ~5 years has a low productivity, even when you consider that you would need less amount of code (than say pure Java) to achieve the same result. I have seen some rock stars producing 50-100 LOC per week in SpringBoot (and that was in the inception phase when there is little refactoring going on). For me, I see a direct correlation between unnecessary structure/conceptual overload and productivity. JavaScript feels just right IMHO.