These are chat archives for jdubray/sam

14th
Jul 2016
Jean-Jacques Dubray
@jdubray
Jul 14 2016 01:37
I may be stepping way out of bounds here, but when you are starting to build something today, you need to consider this, and I would argue SAM is much better prepared for that world:
https://www.youtube.com/watch?v=O-3QwxfPmHY
devin ivy
@devinivy
Jul 14 2016 01:52
@chiwoojo have you looked at all into web components? it could help with your problem.
Vincent Jo
@chiwoojo
Jul 14 2016 03:23
Hi JJ thanks for your thoughts on the wiring, I don't know too much on angular 2 but am curious as to how they work; I might read up some docs on that.. I did see a presentation on angular 2 from the typescript team... It seemed like react + react route + data store
They gave a presentation in Seattle like 4 months ago on using typescript with angular 2
Jean-Jacques Dubray
@jdubray
Jul 14 2016 03:28
TypeScript is definitely a lot better than I thought it would be. It was designed without breaking the spirit of JSON. Hard to believe someone could resist putting a layer of OOP on the pesky extensible data structures.
@chiwoojo what would prevent you to dynamically add the intents to the window object?
Vincent Jo
@chiwoojo
Jul 14 2016 03:33
Maybe because I'm so used to frameworks that does all the click handler binding for me that making this object global makes me feel like it's a little bit hacky; but it can be the only object so I'm slowly getting used to the fact
Global object*
When you say layer of OOP what do you mean?
When you say dynamically did you mean the window.intents or the angular 2 way? Sorry I should have asked this clarifying question first
Jean-Jacques Dubray
@jdubray
Jul 14 2016 04:20
OOP does not allow "extensible" data structures and generally uses getters/setters. I like JSON as a message like structure that I can manipulate as needed.
@chiwoojo now, if you don't use a framework, then actions/model/state should be global? Why would you need to attach the intents to the window?
Jean-Jacques Dubray
@jdubray
Jul 14 2016 08:27
Office hours, if anyone wants to chat (live) about SAM, I have opened a "room" for the next couple of hours
https://appear.in/sam-pattern
Jean-Jacques Dubray
@jdubray
Jul 14 2016 09:17
I had a con call with Michel Weststrate (MobX), here is how it went
https://twitter.com/mweststrate/status/753514689762590720
Vincent Jo
@chiwoojo
Jul 14 2016 15:58
hey JJ, seems like that call went great. That's great to hear.. maybe there will be a framework that will embrace SAM after all :)
I'm interesting in seeing it
I see what you mean by extensible data structures.. yea, getters and setters seem to be a pain
I was thinking about if actions/model/state should be global to the chrome window yesterday..
and I came to the conclusion that I don't see any issues having them global; so I started to experiment my code to use as little build tooling as possible (using it for just css stuff)
but then later that evening, I wasn't really satisfied with the 4-5 script tags that I used (each for model, state, actions, wiring, etc..)
in the html
so I figured out that I can explicit set any variable to the window object without using a 'window.intents' syntax using browserify
Vincent Jo
@chiwoojo
Jul 14 2016 16:04
so right now I feel like I have a really elegant solution I will share with the group here
this is the first file that the Grunt-browserify compiler sees:
blob
I set a setting on grunt-browserify for this file to be available via window.sam
so on my theme.js
I do things like:
blob
Vincent Jo
@chiwoojo
Jul 14 2016 16:09
and my html file looks like this:
blob
and I have all separate files for model, state, util, display function, etc
it's pretty awesome right now lol... a lot of hard work though and spinning around
ohh, and a side benefit from having model not in the window variable maybe good for security maybe?
so people browsing around the app doesn't touch the model on accident... I can define what the API is for my application by only defining intents in the global variable