markerikson

[1:24 PM] mezzopiano: Hi everyone!

I'm building a tree component, and would like to move from a nested representation of the (redux) state to a flat one (in which each node stores the ids of directly nested nodes) because it will make the code simpler (other components access the same data, and even for the tree itself reducers will be simpler because they do not have to traverse the entire structure).

My question is this: This will (I think) require a transformation from the flat to a nested data structure (which I'm worried would break immutability), or individual components (tree nodes) pulling data from the store directly. Which approach would you recommend? Is this a bad idea overall?

Any comments, pointers and suggestions are much appreciated. Thanks a lot!
[1:24 PM] acemarke: @mezzopiano : as it turns out, my own app uses exactly that approach
[1:24 PM] acemarke: each individual tree node is itself connected
[1:25 PM] acemarke: the parent passes in the item's ID as

markerikson

// Reusable utility functions
function updateObject(oldObject, newValues) {
    // Encapsulate the idea of passing a new object as the first parameter
    // to Object.assign to ensure we correctly copy data instead of mutating
    return Object.assign({}, oldObject, newValues);
}

function updateItemInArray(array, itemId, updateItemCallback) {
    const updatedItems = array.map(item => {

markerikson

[9:24 PM] acemarke: the typical complaints are things like switch statements, having to touch multiple files for actions vs constants vs reducers, verbosity of updating nested fields in a reducer, etc
[9:31 PM] acemarke: most of the "ceremony" and "boilerplate" and Redux exists for one of two reasons
[9:32 PM] acemarke: either because it's effectively a prerequisite for Redux's main capabilities and selling points
[9:32 PM] acemarke: or because it's good software engineering practices
[9:32 PM] acemarke: for example:
[9:32 PM] acemarke: * actions and state should be serializable because that enables "time-travel debugging"
[9:33 PM] acemarke: * data should be immutable because you know you're not making accidental modifications, and because it allows very cheap shouldComponentUpdate checks with React
[9:34 PM] acemarke: * since action types need to be serializable, they should almost always be strings, because those are easier to read. And since you'll want to use them in both your reducers a

markerikson

11:02 PM] localjo:: I'm trying to improve my ability to debug a React app. Right now I'm just using console.log all over the place to inspect what's going on and it's slow and tedious. I'd like to take advantage of Chrome Devtools to set breakpoints and step through code, but I'm having trouble because most of the time Devtools is stepping through a bunch of internal React functions and I get completely lost. Is there an easier way to step through just my own code?
[11:08 PM] acemarke: what kinds of stuff are you trying to debug?
[11:08 PM] localjo:: I know Devtools has a blackboxing feature, but the docs for that are outdated.
[11:08 PM] acemarke: in theory, one of the advantages of React is that it should be easy to trace dataflow
[11:09 PM] acemarke: but yeah, my experience is that stepping into React itself is not anything that's going to help
[11:09 PM] localjo:: Hmm, I can't even trace things like what's happening that's preventing a component from re-rendering wh

markerikson

JSX

[8:52 PM] acemarke: okay. It's important to understand that when you write JSX syntax, like , that gets transformed into normal Javascript
[8:53 PM] acemarke: for example, <MyComponent a={123} b="someString" c={aVariable} /> actually becomes React.createElement(MyComponent, {a : 123, b : "someString", c : aVariable})
[8:53 PM] acemarke: in JSX, angle brackets like <> begin JSX syntax, but curly braces like { } actually escape back to normal Javascript
[8:54 PM] acemarke: for example, I could replace the a prop with, say, <MyComponent a={100 + 20 + 3} />

Computed Properties

8:55 PM] acemarke: so. THAT is an example of a new feature in Javascript ES6
[8:55 PM] acemarke: "computed object properties"

markerikson

[9:32 PM] sleepycat: @acemarke also, thanks for writing that stuff about action creators. That's really helpful.
[9:45 PM] sleepycat: @acemarke It feels like the patterns around Redux are still in flux (zing!). My impression is that people are expecting Dan to give them "the right answer™" while the more I read, the more it feels like this is a collective exercise in figuring it out.
[10:06 PM] acemarke: @sleepycat, getting back to your question: like I said, there's a whole bunch of different related responses to that
[10:07 PM] acemarke: one is that "boilerplate" and "too many files" are the most common complaints about Redux
[10:08 PM] acemarke: action creators are definitely "one more thing" to have to write
[10:08 PM] acemarke: and yeah, in the case of a trivial action creator that just immediately returns an action object, probably does seem unnecessary to a lot of people
[10:09 PM] acemarke: 2) While Dan (and Andrew) did a ton of work to put together Redux and wr

markerikson

// See https://rainsoft.io/how-three-dots-changed-javascript/ for more detail on some of these

// ES6 arrays

// Array spread operator
const newArray = [...oldArray, newItem];

// Array destructuring
const [first, second, ...everythingElse] = someArray;

markerikson

[6:34 PM] marekweb: I started using ES6 classes for my React components because ES6 is the new hotness and all that, but I'm realizing that I can't actually name any advantages, and I have to bind methods manually. So why use classes over React.createClass?
[6:34 PM] acemarke: a few reasons
[6:35 PM] acemarke: first, classes are an official part of the language
[6:35 PM] acemarke: second, that means that tooling understands the syntax
[6:35 PM] acemarke: third, createClass is eventually going to be deprecated
[6:36 PM] acemarke: there's various solutions to the method binding issue
[6:36 PM] acemarke: the suggested one is to use the "class properties" syntax, which isn't yet final, but I think may have recently hit stage 3
[6:37 PM] acemarke: ah... no, looks like it's still stage 2. Object spread hit stage 3, that's what I was thinking of
[6:37 PM] acemarke: that said, class properties are well supported in Babel, and used in tools like create-react-app
[

markerikson

[7:50 PM] acemarke: @jon.m : fwiw, I always have learned best when I had a project I was working on, and needed to implement some feature I'd never built before
[7:50 PM] acemarke: nothing motivates you to learn a particular concept or technology like needing it to build a feature
[7:50 PM] acemarke: ie, "learn generators" isn't terribly useful or motivating
[7:51 PM] acemarke: but "I need to make my async code easier to read / build a complex async logic feature, and Redux-Saga requires use of generator functions" is more of a specific motivation
[7:52 PM] acemarke: now, there's nothing wrong with going out and reading up on a specific feature - promises, generators, observables, etc
[7:52 PM] acemarke: always great to have more tools in the toolbox
[7:52 PM] acemarke: but ultimately you need something to apply those tools to
[7:52 PM] CPT: I agree. Having motivation helps
[7:52 PM] jon.m: I keep seeing this TreeHouse commercial on youtube that says a guy g

markerikson

    // Ampersand-State doesn't mix in Underscore methods the way Backbone.Model does.
    // Technically it could also be done as a standalone mixin, but we'll do that here.
    var modelMethods = ['keys', 'values', 'pairs', 'invert', 'pick', 'omit'];

    // Mix in each Underscore method as a proxy to `Model#attributes`.
    _.each(modelMethods, function(method) {
        State.prototype[method] = function() {
            var args = [].slice.call(arguments);
            args.unshift(this.attributes);