These are chat archives for jdubray/sam

25th
Aug 2016
Jeff Barczewski
@jeffbski
Aug 25 2016 00:23
I certainly respect your opinion, but in my 27 years as a professional developer, I've never found a stack that was as nice as the React, Redux, redux-logic, Node.js one I am currently using. I can run the majority of the code on the client and the server and it can even auto upgrade a server rendered page to a full single page app. It's extremely easy to hit API's using any XHR library or web sockets. That's just for web development, if you take into account being able to do native and desktop apps (React Native) in a similar manner reusing a bunch of code, then it is mind boggling. The parts are modular so they can easily be swapped out if something better comes along. If you want to use Preact instead of React, no problem, switch it out and go. If something better than Redux comes out, change it out. Each of these pieces brings tons of value and when I went through the exercise of implementing SAM from scratch, I no longer benefited from that stack and it was painful. I got my vanilla SAM example working, but it didn't have nearly the capabilities that the React, Redux one did. So there is a price to rolling your own even if you are following a pattern. If you don't want or need the functionality that React, Redux provides then by all means use what makes you happy. Personally I like how my code is shaping up currently with this stack and it feels really good to build upon. I can easily compose together things with this stack, so it enables one to build really complex apps without pulling your hair out. I'm always on the lookout for better ways to do things, so that's why I like having these debates so I can better understand and learn new things.
Jeff Barczewski
@jeffbski
Aug 25 2016 00:30
I agree that React is best used as just a function (using stateless function components), but the rest of the component lifecycle is there to help people to migrate to that new way of thinking. It is a bit of a mind shift and React allows them to get their existing stuff working and slowly migrate over rather than having to scrap everything and start over. I like the new way enough, I'd probably just reimplement using a functional style, but some people have to take baby steps and React supports both mechanisms.
Jean-Jacques Dubray
@jdubray
Aug 25 2016 00:30

We are on the same page, the last time I felt such a major step forward was when I discovered NeXTStep in 1990.
That's the most important aspect:

Personally I like how my code is shaping up currently with this stack and it feels really good to build upon.

I still would to like to see more guiding principles on where to plug APIs with React (and ng2).

Jeff Barczewski
@jeffbski
Aug 25 2016 00:34
Yes, I agree. I never did much with the NeXTStep but it had some great ideas. I think the guiding principles should emerge and be documented, that would probably help tremendously.
Vincent Jo
@chiwoojo
Aug 25 2016 01:20

It seems like you guys are having a great conversation... I'm excited to read it thoroughly when I have time later, but JJ's quote stuck out to me when I was skimming/reading:

The biggest lesson behind TLA+ (I don't want to say SAM, because SAM is merely using TLA+) is that factoring is everything, when you get the factoring of your code wrong you enter a maze that you will most likely never exit.

the Maze is real guys
Jean-Jacques Dubray
@jdubray
Aug 25 2016 01:29
+1
devin ivy
@devinivy
Aug 25 2016 02:14

pre-1.0 on this library i wrote for using stateful forms with redux/react, would love input. used SAM-y ideas when designing it. in particular, it assumes there's a reducer out there that's actually accept/rejecting values rather than getting bossed-around by actions. it uses this to detect invalid form fields for free (if the value in the form doesn't match the value in app-state, you have an invalid form field). we talked about this pattern the other day in here, and it's made my life a lot easier recently.

https://github.com/BigRoomStudios/strange-forms

if you have any good ideas about how to display why a field is invalid while keeping validation logic in the reducers, let me know!
devin ivy
@devinivy
Aug 25 2016 02:20
assume there are two text fields that display/update the same piece of state. they should be able to each independently input a bad value and display (potentially) different validation-err messages.
Vincent Jo
@chiwoojo
Aug 25 2016 04:02
I'm reviewing some notes when I was learning Backbone (MVC) not too long ago... and omg... why... in the world did this exist in the first place. If you like to live in a maze and you absolutely love the maze, Backbone is the way to go
devin ivy
@devinivy
Aug 25 2016 11:21
@foxdonut thanks– i will go through that example!
Fred Daoud
@foxdonut
Aug 25 2016 11:22
@devinivy btw you can run it here (just in case you didn't see what I wrote above): http://meiosis.js.org/examples/temperatures/index.html
devin ivy
@devinivy
Aug 25 2016 11:24
this is a little different. your model doesn't keep the valid value, does it?
Fred Daoud
@foxdonut
Aug 25 2016 11:24
how do you mean?
devin ivy
@devinivy
Aug 25 2016 11:26
i want my model to only keep valid values, assuming those values will be used not just in this form but throughout the rest of the app as well.
so an invalid date would not make it into the model.
Fred Daoud
@foxdonut
Aug 25 2016 11:27
right. so in this example, the "saved" property of the model contains only valid values.
if you enter something invalid and press Save, the "saved" property does not change.
devin ivy
@devinivy
Aug 25 2016 11:37
ah i see!
now, if you had several forms for the same field how would you approach it?
we took a very different approach, which is interesting :)
my approach is as such... there's an action that tries to update the temperature. whenever you change its value in the form a proposal is made to the model. the model accepts it if it's a valid temperature value, or otherwise rejects it. in the case even a misuse of actions would not allow a "bad" state.
Fred Daoud
@foxdonut
Aug 25 2016 11:43
I would do as the temperature controls in the example, i.e. I would nest the forms each at their own section of the root model. If they would be the same field (i.e. just "temperature", not separate air/water), then each form would propose its value, and the root receiver would accept valid values into the model. Does that make sense?
Ah, I see. In your case, you propose everything to the model, and the model validates. In my case, each component has its model which validates the proposed values, and only proposes valid values to the model that is "higher up". What I like about this is encapsulation, it groups things together nicely.
Fred Daoud
@foxdonut
Aug 25 2016 11:48
It also makes things reusable. I could have multiple instances of the "date" component, and each would have its own state, validation error message, etc. I think this is what you were asking about earlier, yes?
it would look something like
const dateComponent1 = createComponent(nestComponent(date(Action), "store.date1"));
const dateComponent2 = createComponent(nestComponent(date(Action), "store.date2"));
devin ivy
@devinivy
Aug 25 2016 12:28
sorry, had a little commute!
Fred Daoud
@foxdonut
Aug 25 2016 12:32
no problem! :D
devin ivy
@devinivy
Aug 25 2016 12:48
@foxdonut would you approach common validation (say, of the same fields) simply by breaking validation into its own module and reusing it across all the form reducers?
devin ivy
@devinivy
Aug 25 2016 13:00
hmm i'll think about it more. what i'm really aiming for is validation to happen on a single value in the model. that's partly because it makes it easy to implement forms into a pre-existing model. but also because validation should already occur on that value in the model. as i see it, the reducers shouldn't trust the forms to save() that value correctly when it's time to do so.
Jean-Jacques Dubray
@jdubray
Aug 25 2016 13:05
@devinivy actions are responsible for the first line of validation. Actions should be responsible for presenting reasonably well formed proposal, or if they detect an error, an "error proposal" that gets rendered in the state representation. Otherwise I agree, model should do its own validation, especially integrity check (with other values). Have you considered Strummer for that role?
Fred Daoud
@foxdonut
Aug 25 2016 13:05
@devinivy Sure. FWIW, that last example could just as well be for validation of a single value in the model. In the temperature example, this could be broken out into its own module, exposing a validate(model) function: https://github.com/foxdonut/meiosis-examples/blob/master/examples/temperatures/entry/receive.js#L5-L14
devin ivy
@devinivy
Aug 25 2016 13:06
thanks @jdubray @foxdonut :)
@jdubray i have looked at strummer since you mentioned it before
Fred Daoud
@foxdonut
Aug 25 2016 13:07
@devinivy Welcome! Always nice to have these discussions. :thumbsup:
Jean-Jacques Dubray
@jdubray
Aug 25 2016 13:07
:thumbsup:
Fred Daoud
@foxdonut
Aug 25 2016 13:09
I agree with @jdubray I also think validation should be done in the "first line of defense" before presenting to the "root" model. Else, the root model could become unreasonably complex in having to deal with all subcomponents' validation rules and so on. I find it cleaner to have each subcomponent be well-encapsulated. Makes code much easier to manage.
devin ivy
@devinivy
Aug 25 2016 13:13
yup, makes sense. i think i know where to focus now for that project i posted above. i'll think of its current behavior as "default" (compare the value displayed in the form to the value stored in the model, and if they're different, the value is invalid).
it's a good, cheap default. then allow validation with messages to be placed on top of that if desired.