Tag Archives: React

On MobX Redux dilemma

In my experiences using MobX as a state management library produces less code and lets you get things done quicker (two-folded knife!) but with Redux you get a lot of stuff for free – most notable is scalable approach to architecture and maintenance of web applications.

I personally prefer Redux also because it’s functional like React which puts a lot of emphasize on functional stateless components and it makes me feel like a JavaScript developer. While that means it’s more verbose, it contains minimal abstraction and thus is easier to debug.

New React Context API

I like new react API for creating and using context. It feels right. One thing I immediately tried to do was creating a helper which simplifies consuming multiple contexts. Because they create context hell. When you component uses more than one context and because of a children as a function pattern (which is basically the same as render props pattern where component’s children function is specified as a component’s prop named render), code gets familiar indent to the left (callback hell).

For example with the use of this helper,

<Theme.Consumer>
    { theme => (
        <Language.Consumer>
            { language => (
                <App theme={theme} language={language} />
            )}
        </Language.Consumer>    
    )}
</Theme.Consumer>

would become

<Consume contexts={[Theme, Language]}>
    { (theme, language) => (
        <App theme={theme} language={language} />
    )}  
</Consume>

But after giving it a second thought, I realized in high-performance web applications this “multiple contexts consumer” case scenario can be a bad idea in most cases. Because If we have for example two contexts that are always used together, it’s better to just have one context anyway. But if a component uses more contexts which aren’t co-dependent, that means parts of component will be re-rendered unnecessary. So the component should be split into components which uses only one context or co-dependant contexts.

If you are interested in Consumer component, you can see it in following snippet with example usage. I’ve also added Provide component which mirrors Consume component for the sake of completeness. It’s no problem though if you specify Providers separately or not at all – in that case it will use context’s default value than).

Libraries over frameworks

Lately (in term of years) I noticed I prefer using libraries over frameworks. Or in other words I like to use packages that each do their one thing well rather than one package with all batteries included. I recognize both libraries and frameworks have their pros and cons.

You can see my preference for libraries if you are reading my blog where I write a lot about web development, specifically about React and Go. Well, Go is a programming language but because it has an excellent standard library, there’s actually no need for a framework.

The most obvious advantage of using libraries over frameworks I have are:

  • I have a freedom of putting all pieces of an application as I see fit and only those necessarily.
  • I can easily replace one piece after another, better option appears.
  • they take less time to learn.
  • feeling I have a control over them not other way around.
  • process of updating a library is less painful.

The biggest pain point is writing boilerplate after starting every new project. But this is solvable by maintaining your own starter/base/boilerplate. I don’t like using boilerplates from other people because they don’t fit my mental model (but that doesn’t mean I don’t like inspecting them for fresh ideas on how to I improve my own boilerplate).

Disadvantages of using frameworks I’ve experienced so far are:

  • hard to learn
  • developing in it I often don’t feel like a [insert a programming language] developer
  • learning specifics which are in general useless instead of core programming concepts, computer science that can be reapplied to every new project.
  • using only small subset of features or fixing a bug? Too bad, you have to learn all of it so that you might not break anything.
  • having to conform to specific mindset and way of doing things because framework is designed for doing things THAT way (convention over configuration).

I only enjoyed using/learning frameworks at the beginning of my career because I didn’t exactly know what a modern applications consist of. After years of learning how to architecture an application (folder structure, design patterns etc) on my own or from popular frameworks I became confident in doing them from scratch with the help of libraries that aren’t limiting my creativeness.

The best way of rendering a collection of items in React/Redux

In short

The best way to render a collection in React, backed by Redux or other similar library: store a collection as an object where key is item id and value is item itself. That way when rendering collection, pass only item’s id to the item component. Than in item’s connected component query a collection by item’s id you passed early. So something like this.

//Item.js
import React from 'react'
import {connect} from 'react-redux'

const Item = ({item}) => {
    // use item to render markup
}

const mapStateToProps = state, {id} => ({
    item: state.collection.data[id]
})

export default connect(mapStateToProps)(Item)
// Collection.js
import React from 'react'
import {connect} from 'react-redux'
import Item from './Item'

const Collection = ({ids}) => (
    <div>{ids.map(id => <Item key={id} id={id} />)}</div>
)

const mapStateToProps = state => ({
    ids: state.collection.ids // actual collection is obtained with state.collection.data 
})

export default connect(mapStateToProps)(Collection)

Storing collection as an object also improves performance of querying and deleting an item from it.

Longer explanation

When I began developing in React a few years ago I was rendering a collection of items this way:

items.map(item => <Item {...item} key={item.id} />)

Then Flux/Redux came in my way and I realized storing items in state as a list of items is inefficient as noted. That’s because querying a list is O(n) operation but querying an object only O(1).

Given that performance boost I was still rendering a collection as before only now I had to turn an object into a ordered list because .map() only works on lists. Imagine doing that after every render! Using reselect can improve this by only converting it to list when collection changes. But we can still do better than that.

Satisfying solution came after reading a blog posts about making React and Redux more performant together. The point I think was “don’t be afraid of using connect often and breaking reducer into smaller reducers”.

You can build object of (id, item) pairs yourself or use library like normalizr which normalizes input data according to provided schema and returns entities and result (ids).

The reason why I prefer this method over previous is also because I love to use functional programming in react/redux. I think those two are brilliant couple. But to make functional programming easier, I use utility libraries. The two most known are lodash/fp and ramda. Lodash/fp might be superior to ramda when it comes to amount of functions included but I love ramda more because of the documentation. It’s easier to find what you are looking for (in lodash/fp I need to look at two places).

I was indecisive though which one to pick and stick with before discovering this new way of rendering collection because ramda doesn’t support iteration over an object.