markerikson

import React, {Component} from "react";
import {connect, Provider} from "react-redux";
import autoBind from 'react-autobind';
import Box, {Container, VBox, Page} from "react-layout-components"

import fireflyIcon from "./Firefly.png";

import {INCREMENT_COUNTER, DECREMENT_COUNTER} from "../constants/ActionTypes"

markerikson

import {bindActionCreators} from "redux";
import {connect} from "react-redux";
import {action1, action2} from "myActions";

// A reusable utility function that binds action creators
// and returns them as a prop named "actions"
function prepareActions(actions) {
    return (dispatch) => ({
        actions : bindActionCreators(actions, dispatch);
    })

markerikson

[6:19 PM] acemarke: the important thing is that when you use combineReducers, you're defining the key names, and which function should handle the portion of state at that key
[6:19 PM] Nigel: oh
[6:19 PM] Nigel: okaaay
[6:19 PM] acemarke: and when you use the object shorthand, like {change_points}, you're saying "create an object that has a key named 'change_points', and use the function named 'change_points' as the value"(edited)
[6:20 PM] acemarke: so if you want to use state.points as the name for that chunk of data, you have to be consistent in how you define it and how you access it
[6:21 PM] acemarke: and, when your change_points() function gets called, it will only be given the portion of data attached to that key. so, if it initially returns state = 0, then next time it's called, it will only be given 0 again, not {points : 0}
[6:21 PM] acemarke: it doesn't even know it's attached to a key named "points"
[6:21 PM] acemarke: does that make sense?
[6:23 PM] Nigel: Okay thx a lot, I didn

markerikson

    export default function applyMiddleware(...middlewares) {
        return (createStore) => (reducer, preloadedState, enhancer) => {
            // snip actual enhancer logic

            return {
                ...store,
                dispatch
            }
        }

markerikson

[10:36 PM] acemarke: @Francois Ward : hey, you guys have a whole bunch of apps going on. Any thoughts on forms? https://news.ycombinator.com/item?id=11890229
[10:39 PM] Francois Ward: yeah. They're generally non-standard forms (like task lists, etc) or one off text fields, etc, rarely full blown forms, so it's not a problem that we tackled a whole lot. Some people are experimenting with redux-form, because the v5 API is pretty simple and essentially just reduces typing (::shrugs::). The new API in v6 is very different and is much more intrusive, so there's less interest in that.
[10:39 PM] acemarke: "more" intrusive? I though the point was that it was less so
[10:39 PM] Francois Ward: Personally, I feel like forms in any substantial, high quality product need to be properly designed and engineered, so using a generic form framework will never give you "quite" the thing your designer may want, so I prefer hand coding them.
[10:39 PM] acemarke: pick-and-choose, more pinpoint-ish, ra

markerikson

[12:02 PM] jimbolla: Oh hey that's me. (The complete rewrite, not the GIF guy). I'd love to hear your thoughts on that work.
[1:23 PM] acemarke: @jimbolla my thoughts on the topic are... mixed, at the moment
[1:23 PM] acemarke: first, I'd definitely agree that the implementation of connect() has gotten significantly hairier and harder to follow as support for additional optimizations and use cases has been added
[1:24 PM] acemarke: which is why there's that PR/discussion of trying to separate the implementation of caching and such
[1:26 PM] acemarke: second, you seem to be a pretty productive dev, have put actual time/thought/effort into your reimplementation, and are taking a reasonable approach to offering it up for discussion
[1:29 PM] acemarke: third: as I said in that "gif-ful" pull 1813 discussion, I have commit access, but basically limit my actual repo activities to doc improvements and responding to issues. I do have opinions, but don't generally see myself as a fin

markerikson

class ChildComponent = (props) => <div>{props.name}</div>;

class MyComponent extends Component {

    renderItem(item, index) {
        return <ChildComponent key={index} name={item.name} />
    }
    
    render() {
        const {list1, list2, list3} = this.props;

markerikson

class ChildComponent extends React.Component {
    constructor(props) {
        super(props);
        this.state = {
            counter : 0
        };
        
        this.onButtonClick = this.onButtonClick.bind(this);
    }
    

markerikson

import {combineReducers} from "redux";
import reduceReducers from "reduce-reducers";


import reducerA from "./reducerA";
import reducerB from "./reducerB";
import specialCaseHandler from "./specialCaseHandler";


const combinedReducer = combineReducers({

markerikson

[04:52 PM] acemarke: Question for y'all. I'm trying to define some semi-official-ish terminology for common types of functions that show up when writing reducer logic
The original reason for the term "reducer" is that it takes (state, action) and returns the new state, same as a callback to reduce()
Does it make sense to still use the word "reducer" when describing functions that are used inside of reducer logic, but do not have the exact (state, action) signature?
[04:57 PM] acemarke: Some examples might be:

• a function that handles a "cross-slice" action, like const newSliceA = handleSomeCase(state.a, state.b)
• A function that handles a specific pattern that occurs inside of multiple cases, and each case calls this function to do part of the work

[05:22 PM] totaldis: how is that a reduce?
[05:22 PM] acemarke: that's kinda what I'm asking
people generally throw around the phrase "reducers" to mean "any function at all that gets called somewhere inside that log