markerikson

May 12, 2016

[8:23 PM] jrajav:: Heya. I'm wondering what the function of components really are. Just don't fully understand - why not just pass in the state with something like store.subscribe( () => render( , document.getElementById('root') ) ) ?

[8:24 PM] jrajav:: Passing in dispatch functions as well

[8:24 PM] jrajav:: Then, split apart the state as appropriate further down for each subcomponent

[8:25 PM] jrajav:: If all of the components are pure, stateless functional components this approach should still be just as performant, right?

markerikson

function timerMiddleware({dispatch, getState}) {
    const timers = {};
    
    

    return next => action => {
        if(action.type == "START_TIMER") {
            const {action, timerName, timerInterval} = action.payload;
            
            clearInterval(timers[timerName]);

markerikson

const mainReducer = combineReducers({a, b, c});

const secondReducer = function(state, action) {
    switch(action.type) {
        case SOME_ACTION:
            return someSpecificReducer(state.a, state.c);
        default: return state;    
    }
};

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

[12:03 AM] acemarke: "controlled" and "uncontrolled" inputs
[12:04 AM] acemarke: if I have a plain, normal HTML page, and I put <input id="myTextbox" type="text" /> in my page(edited)
[12:04 AM] acemarke: and I start typing into that textbox
[12:04 AM] acemarke: it remembers what I've typed. The browser stores the current value for that input
[12:05 AM] acemarke: and then sometime later, I can get the actual element, say, const input = document.getElementById("myTextbox"), and I can ask it for its value: const currentText = input.value;
[12:05 AM] acemarke: good so far?
[12:08 AM] acemarke: I'll keep going, and let me know if you have questions
[12:08 AM] lozio: ok, actually I'm reading
[12:09 AM] lozio: good
[12:09 AM] acemarke: so, a normal HTML input field effectively stores its own value at all times, and you can get the element and ask for its value

markerikson

// approach 1: define action object in the component
this.props.dispatch({
    type : "EDIT_ITEM_ATTRIBUTES", 
    payload : {
        item : {itemID, itemType},
        newAttributes : newValue,
    }
});

// approach 2: use an action creator function

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;