These are chat archives for jdubray/sam

30th
May 2016
Jean-Jacques Dubray
@jdubray
May 30 2016 00:14
I didn't realize that mobx was from Mendix https://github.com/mobxjs/mobx
Anton Stoychev
@antitoxic
May 30 2016 10:16

@509dave16 thank you. I will give you some feedback after a while. The tic-tac-toe example is overwhelming especially with all the mapping intent_types->intents->redux actions. Btw, is it impossible with SAM+redux to go without type for the SAM actions. From our conversation with @jdubray I thought setting payload identifier is an antipattern.

@jdubray is mobx something playing well with SAM?

Jean-Jacques Dubray
@jdubray
May 30 2016 11:31
MobX shares some concepts, for instance it shows that an immutable Model (such as Redux reducer + store) is highly unnecessary, but it is lacking the propose/accept/learn structure.
Jean-Jacques Dubray
@jdubray
May 30 2016 12:40

@antitoxic

I thought setting payload identifier is an antipattern.

I would not call it an anti-pattern, I just feel that the model shouldn't have to know about the multiplicity of action types, but clearly, it is impossible to never use action types. For instance "increment" or anything related to collections (add, remove,...) requires some form of action type to instruct the model what to do.

When you don't use action types, you have to probe the dataset to understand what to do with it.
That's why I call it a preference, I prefer datasets because I don't want the model to know a lot about the actions or the state function. I favour decoupling.
Jean-Jacques Dubray
@jdubray
May 30 2016 12:50

MobX is also showing that:

working with subscriptions (or cursors, lenses, selectors, connectors, etc) has a fundamental problem: as your app evolves, you will make mistakes in managing those subscriptions and either oversubscribe (continue subscribing to a value or store that is no longer used in a component) or undersubscribe (forgetting to listen for updates leading to subtle staleness bugs).

that being said, it's hard for me to agree with MobX reactive view of the world. Michel presents his framework as something that works like Excel where changes on "observables" triggers a series of "compute" operations. The UI is updated following an observer pattern.

The event/event handler architecture is the problem, no matter how you wire it (here observable/computable+observer)
Jean-Jacques Dubray
@jdubray
May 30 2016 13:06
blob
Jean-Jacques Dubray
@jdubray
May 30 2016 13:16
I'd like to reiterate that the problem with Front-End architecture is to properly mutate application state, and that problem is increasing in complexity with modern UX.
The problem is not about better wiring or increased testability. To paraphrase Churchill, our industry always end up doing the right thing, after trying everything else.
Jean-Jacques Dubray
@jdubray
May 30 2016 14:17
If you find your testers splitting up functions to support
the testing process, you’re destroying your system
architecture and code comprehension along with it.
Test at a coarser level of granularity.
David Fall
@509dave16
May 30 2016 14:23
@antitoxic Yeah. I need to better document what's going on there. I refer to them as 'intents' instead of 'action creators' , because 'actions' mean something else in SAM. The project was sort of an experiment to see if I could avoid having multiple reducer files with switch statements. This required generating what intent types(i.e. action types) the reducers handled based off of the return values from the 'intent' functions, which contained the 'type' and 'payload' in an object. In addition, each of the keys on the 'payload' object had to exist as one of the keys exported from 'reducer-defaults.js'. My apologies for the confusion.
Anton Stoychev
@antitoxic
May 30 2016 14:36
@509dave16 I've been meaning to ask you: Shouldn't SAM's actions be passed as properties to React components?
Anton Stoychev
@antitoxic
May 30 2016 14:55
download.png
@jdubray please don't rain rage against the graphql bit (i'm not using relay or anything, just using graphql for getting data)
The important thing is whether this is what SAM suggest
many SAM instances in single frontend
Anton Stoychev
@antitoxic
May 30 2016 15:07

I created the diagram using @jdubray example: https://github.com/jdubray/sam-samples/blob/master/react-child-instance/index.html

Both the example and this diagram don't excite me much. Looks like I will store same data in many models. The example does this for name, email and password. So there won't be a single source of truth?

Anton Stoychev
@antitoxic
May 30 2016 15:42
download2.png
I would personally prefer this
Where I split my SAM state function into several React Container components but I keep my model in 1 place.
Here's the draw.io link for reference (includes both diagrams): https://drive.google.com/file/d/0B4QEIaPHnvx6UlN4TzVGdHBpNnM/view?usp=sharing
David Fall
@509dave16
May 30 2016 15:58
@antitoxic Yes. Technically I should be passing the actions to the State Representation(View). I am working on a little refactor for that.Those diagrams were very good. I agree with you that it would be easier to have Container components manage a specific property or set of properties on the Model. Versus having to manage multiple SAM instances and the communication between them.
Jean-Jacques Dubray
@jdubray
May 30 2016 16:45

@antitoxic

Looks like I will store same data in many models.

well, you wanted to not pollute the application state with form validation errors. You have to pick one. You can't have both at the same time, can you? In any case, you don't really store it in different places, once the child has submitted its data to the parent, it no longer exists, so the data is only in one place at a time.

Anton Stoychev
@antitoxic
May 30 2016 16:48
@jdubray you're being an ass. I was asking what SAM plans to do not to pollute the model. Apparently it's ok to pollute the model. And "once the child has submitted its data to the parent, it no longer exist" is only in your example case. Rarely this is the reality.
Well, I give up, good luck SAM guys.
SAM currently holds no benefit whatsover to any of the alternatives. No good docs, no good discussions, no good tools.
weepy
@weepy
May 30 2016 16:54
@antitoxic not sure what I said could have triggered that kind of response, but hey, we live in a free society, you are entitled to your opionions.
weepy
@weepy
May 30 2016 18:38
firebase is kinda awesome
Jean-Jacques Dubray
@jdubray
May 30 2016 21:42

@509dave16

Technically I should be passing the actions to the State Representation(View

this does not sound right, sometimes its ok for the model to know about which action triggered the mutation, I can't think of a case where the View components would need to know about it. Could you give an example?

David Fall
@509dave16
May 30 2016 22:05

@jdubray This is just a brief example:

import React, {Component} from 'react'
import { connect } from 'react-redux'
import RoundButtonGroup from './../presentational/RoundButtonGroup';

const mapStoreToProps = (store, ownProps) => {
  return {
    selected: store.gameType,
    buttons: ownProps.buttons,
    clickHandler: (gameType) => ownProps.actions.setGameTypeAction(gameType)
  };
};
const GameType = connect(mapStoreToProps)(RoundButtonGroup);
export default GameType;

Container Components need to provide Presentational Components with event handlers that should be triggered. The Container Components need access to the Actions that should be utilized in or as event handlers.

Jean-Jacques Dubray
@jdubray
May 30 2016 22:08
Sorry, of course, you need to pass a pointer to the handler, since we were talking about action types, I felt that was the context of the comment.
David Fall
@509dave16
May 30 2016 23:27
@jdubray No problem. Always glad to clarify.
Jean-Jacques Dubray
@jdubray
May 30 2016 23:34
@509dave16 I added a link to your repo on sam.js.org, hope it's ok and tweeted it