These are chat archives for jdubray/sam

23rd
Oct 2016
Charles Rector
@chuckrector
Oct 23 2016 02:36
here is a wip of v5 of scene editor -- no functional changes yet, but mainly refactoring of architecture from topics we discussed:
http://codepen.io/chuckrector/pen/394d422db2e237ed871cda77cb1ab1f0/
  1. more consistent model shape (though for deleteSprite i still delete from model.sprites)
  2. more normalized model, with sprites keyed by id and scene as an ordered list of ids
  3. model is grouping all dragging info together in dragInfo with true boolean for isDragging
  4. all actions have {type, payload} format where type is one of actions.intents
  5. now only single id reference for highlighted & selected sprite at model top level, rather than per sprite flags
  6. state.representation now computes intermediate view model as a flat ordered array of sprites, with isSelected or isHighlighted flags computed
This message was deleted
Jean-Jacques Dubray
@jdubray
Oct 23 2016 10:08
@foxdonut @edmulraney @imnutz @inrix-vincent-jo I found this library that allows you to make synchronous HTTP calls and it solved what I was looking for. All static files on my blog are now automatically saved (as blog posts get created) and fetched from S3.
Edward Mulraney
@edmulraney
Oct 23 2016 12:02
@jdubray interesting find
Jean-Jacques Dubray
@metapgmr_twitter
Oct 23 2016 14:08
@chuckrector I like your code, it's so well written. I would say a virtual-dom library would make a lot of sense in this case since each update is rather incremental compared to the state representation.
The general intent of the articulation view->model is to be able to create view components that know nothing about the model. From what I can tell, you have not taken advantage of that capability. In general, you would want to implement a dynamic wiring mechanism (view what I call intent)
$(document.body).on(`mouseup`, `.viewport`, event => {
  event.preventDefault()

  if (model.dragInfo.isDragging) {
    actions.endDraggingSprite()
  }
})

It could look like this:

    actions[`endDraggingSprite`]()

You really want to view to share as little as possible with the Model.

Jean-Jacques Dubray
@metapgmr_twitter
Oct 23 2016 14:13
I learned something today, awesome!:
if (at >= 0 && at < scene.length - 1) {
   ===>>>  [scene[at + 1], scene[at]] = [scene[at], scene[at + 1]]
}
Charles Rector
@chuckrector
Oct 23 2016 16:51
@jdubray re: well written, thank you!
virtual-domI will try that out soon now I think -- the "interruption" of my animations due to full dom rewriting feels quite janky.

view->model

I'd love to hear more on that, since your example of intents is, as far as I'm aware, 100% equivalent to the way I am calling the action. trying to understand how the call notation makes any difference (jshint for example would complain about the indexing and tell me dot notation is more concise)

learned something

destructuring in es6 is so wonderful!

Jean-Jacques Dubray
@jdubray
Oct 23 2016 17:12
This kind of wiring would obviously hard wire the view component to the actions: actions.endDraggingSprite(), it's not mandatory, in general you would not want that. It's not a deal breaker by it would be best some use a dependency injection mechanism to route the call to the application's action.
Charles Rector
@chuckrector
Oct 23 2016 17:26
hmm, i should probably make this a github project so that i can actually split the view etc. into different modules and get a firmer sense of who is depending on whom
i will read more examples with intents and see if i can better understand
Jean-Jacques Dubray
@jdubray
Oct 23 2016 17:28
That would be nice, that also allow us to work on branches
Charles Rector
@chuckrector
Oct 23 2016 17:28
for example, i can see how actions[intent]() is dynamic, yet there is seemingly no value to a literal call ala actions['endDraggingSprite']()
ah, good point. i will do that soon then.
Edward Mulraney
@edmulraney
Oct 23 2016 17:29
----- agreed - there's no difference betweens actions.blah and actions["blah"]
Jean-Jacques Dubray
@metapgmr_twitter
Oct 23 2016 17:33
I see, I see now.
Charles Rector
@chuckrector
Oct 23 2016 19:29
i broke up into actual commits starting w v3 to show a bit of the progression thus far
i used node/express tho will prolly move to webpack
Charles Rector
@chuckrector
Oct 23 2016 19:37
hmm, in fact. i think i will do that now so i can have modules
i cannot even require anything from app.js atm
Jean-Jacques Dubray
@jdubray
Oct 23 2016 19:40
you can use Google traceur, that's a light weight way (non prod) to use es6
Charles Rector
@chuckrector
Oct 23 2016 19:42
but i am already using es6, such as destructuring and template strings -- it is quite well supported in all modern browsers. only not in internet explorer
inability to require is due to app.js inclusion from index.html -- it is only browser js at that point, and not node -- only server is node
Charles Rector
@chuckrector
Oct 23 2016 19:48
huh, perhaps i am wrong on modules. i thought they were only in es7
Charles Rector
@chuckrector
Oct 23 2016 19:55
it is odd that there are many articles on the web about "es6 modules" and yet http://kangax.github.io/compat-table/es6/ does not list modules
Charles Rector
@chuckrector
Oct 23 2016 20:20
traceur is quite lightweight, thank you! it gave me a little trouble, but i figured it out. and i couldn't get the similar babel-standalone to work at all with modules
the trouble was that import foo from `./foo.js` will not work
the problem is the template literal -- apparently potentially dynamic things cannot be used in that context. i noticed the same when dealing with webpack previously
Jean-Jacques Dubray
@metapgmr_twitter
Oct 23 2016 20:22
glad it was helpful
devin ivy
@devinivy
Oct 23 2016 20:22
yes- the idea with ES modules is that they can be statically analyzed. so no dynamic stuff!
Charles Rector
@chuckrector
Oct 23 2016 20:23
cool, i learned something. i started using template literals for all strings after reading a ponyfoo article. so it has been interesting to see where they do not work when applied blindly. i've had similar learnings come out of never using semicolons
i really want to understand what on earth is going on with es6 module support in browsers. kangax compat table is my go-to for checking support, but i suppose it is out of date if it does not list es6 modules :^\
Jean-Jacques Dubray
@metapgmr_twitter
Oct 23 2016 20:43
it should work better in developer mode(?)
Charles Rector
@chuckrector
Oct 23 2016 20:46
@jdubray yes, traceur is working wonderfully -- i do believe i am using in dev mode, by only including those <script> tags and compiling on-the-fly
separately, i am simply confused by the state-of-the-art on es6 modules, i suppose. in terms of kangax compat not listing them
i do see they are listed in the es2015 spec as well
Jean-Jacques Dubray
@metapgmr_twitter
Oct 23 2016 20:48
@edmulraney Yes this is a foundational article, you will note that except for famous all approaches are 3-legged (VMX) and there is no decoupling between the view and the model. It's pretty much hardwired via a change detection mechanism. IMHO, that's a problem.
@chuckrector glad you like it, that's pretty much all I can master (and the angular-cli), so I don't have a choice.
:-)
Charles Rector
@chuckrector
Oct 23 2016 20:50
hah! i'm sure you could master anything
ah, i see why modules are not listed in kangax compat now. it is a testability issue -- kangax/compat-table#316
you would think they would at least note this on the page somewhere, rather than requiring a google search
Charles Rector
@chuckrector
Oct 23 2016 22:56
huh. interestingly, traceur breaks my app, as it seems to muck with the scope
e.g. the onclick events can no longer find actions. i suppose that means traceur probably wraps my app.js in a closure or something, such that all my variables are no longer in the global scope
Charles Rector
@chuckrector
Oct 23 2016 23:18
that brings up an interesting aspect of generating state representations in this way though, which is that onxxx attributes for event handlers tie you to the global scope or the scope of the element (?)
for example, whereas onclick="someAction()" must have access to someAction in the global scope (or this.someAction on the element), someElement.addEventListener(`click`, someAction) has no such restriction... though it would need to be called after the state representation generation. but then your events are no longer colocated with the elements that fire them
hmm, though onClick={this.someAction} in React is getting the event off the element too
ah, but of course it also allows onClick={someAction}... so it can truly overcome that restriction
Charles Rector
@chuckrector
Oct 23 2016 23:23
i.e. a function could be passed from anywhere