These are chat archives for jdubray/sam

14th
Oct 2016
Fred Daoud
@foxdonut
Oct 14 2016 15:40
@jdubray nice article that you linked to! for point no. 6, what if you also need the order's products to be in a certain order? would you add productIds: ["id5", "id2", ...] under ordersById.14e743f8-8fa5-4520-be62-4339551383b5 ?
{
  "productsById": {
    "88cd7621-d3e1-42b7-b2b8-8ca82cdac2f0": {
      "title": "Blue Shirt",
      "price": 9.99
    },
    "aec17a8e-4793-4687-9be4-02a6cf305590": {
      "title": "Red Hat",
      "price": 7.99
    }
  },
  "ordersById": {
    "14e743f8-8fa5-4520-be62-4339551383b5": {
      "customer": "John Smith",
      "products": {
        "88cd7621-d3e1-42b7-b2b8-8ca82cdac2f0": {
          "giftWrap": true,
          "notes": "It's a gift, please remove price tag"
        }
      },
      "productIds": ["id5", "id2"],
      "totalPrice": 9.99
    }
  }
}
Jean-Jacques Dubray
@jdubray
Oct 14 2016 16:07
IMHO "order" is the responsibility of the state representation. The order is (in general) irrelevant to the model. That's another reason why you need to decouple the model from the view via the state representation (which would interpret an attribute value -sort ascending and an array and produce what's needed for the view.
Vincent Jo
@inrix-vincent-jo
Oct 14 2016 17:51
reading the article now, and I'm really liking the writing / ideas so far.. I'm only at #2
Fred Daoud
@foxdonut
Oct 14 2016 17:51
@jdubray I agree with you 100%.. I did not formulate my question properly. I am in tune with your thinking and that of the article's, that the model only contains what's relevant to the model, and no duplicate information. My question would be, instead, the "final" view-data produced for the view to consume (by the state representation). Then, and following the last part of recommendation no. 2, wouldn't you need both the "products" map and the "productIds" array?
Charles Rector
@chuckrector
Oct 14 2016 21:03
i recently read that article too and i loved it. i have recently been exploring redux for representing state of my retro 2d game tile-map editor. by a lot of twitter threads, eventually learned of SAM and working to understand it too. the comment on order being responsibility of state representation is interesting to hear, since in my 2d tile map, a single layer of 100x100 tiles is a linear array of 10,000 elements and the order is quite important there. trying to normalize to a list of plots seems like it would ramp complexity (maybe render via trie or something?) and make rendering slower. for now, immutably generating new layers on each plot doesn't seem to be bad, esp. w immutable.js which i've also been trying out recently
i don't like that immutable.js adds all the api for .get() etc tho, and all the normal notation no longer works :^( one appeal of SAM to me is sticking with just plain ES6
Charles Rector
@chuckrector
Oct 14 2016 21:08
tho it is nice in some cases for setting/getting nested data via setIn/getIn when, like in my case, i haven't yet tried normalizing "map contains map layers" to "list of layers with ids + map" and then referencing layers everywhere by id and whatnot
i am still learning about SAM, but it seems more like there is less restriction on model state "shape" and immutability but more emphasis on flow of control according to all the TLA+ goodness
Charles Rector
@chuckrector
Oct 14 2016 21:13
it is appealing that SAM could allow me to do simple & fast layer[(y*w)+x]=newTileIndex instead of offset=y*w+x, return [...layer.slice(0, offset), newTileIndex, ...layer.slice(offset+1)] shenanigans in reducers
i keep that all in my redux store so i can reload my map editor session to previously loaded map, including all undo history. and i save the session for any map opened, so i effectively get "infinite undo" across all map editing sessions
Fred Daoud
@foxdonut
Oct 14 2016 21:25
@chuckrector interesting, thanks for sharing your experience.. one comment, about "tho it is nice in some cases for setting/getting nested data via setIn/getIn", I've been using object-path in some meiosis examples and it works quite nicely with plain JS objects.
Charles Rector
@chuckrector
Oct 14 2016 21:27
oo, i will have to try those out then. thanks! :^D
i see you are the author of meiosis 👏 and the approach is SAM-like. or at least, proposal/acceptance of changes is a new idea to me i have only seen in SAM so far. i really like idea of not having to jump thru all the immutable hoops tho. at least while learning
Charles Rector
@chuckrector
Oct 14 2016 21:35
that is one of the first stumbling blocks in my understanding i am working to resolve: how proposals are different from redux reducers, which essentially pick from among "proposed" actions anyway to generate a new suitable state. by returning a new value, it has accepted them. or that is my naive understanding so far
(i have a lot of literature to read and catch up on)
Fred Daoud
@foxdonut
Oct 14 2016 23:27
@chuckrector indeed meiosis is my attempt at supporting the wiring to implement SAM. I really like the idea of view = function(model), and the propose - receive - model change - rerender view cycle. My goal is to let people use what they want, so it's your choice whether to use plain objects, immutable.js, or something else.
Using immutable objects is definitely not a requirement, and using plain JS objects is not an obstacle to having devtools to rewind/replay sequences. If you look at this example, you can do a few things in the UI, then use the slider in the upper-left corner.
You can even type in the bottom textarea, e.g. "description": "type here". This shows the view = function(model) nature, since the model is what is shown in the bottom textarea, and the view re-renders when you change it.