Tom Clarkson

Reducing React / Redux boilerplate with ES.Next

Wed, 18 Jan 2017 12:00:00 +0000

I’ve been working with React and Redux for a while now. To start with I was mostly working from the standard React/Redux example, which meant I ended up with rather a lot of components that look like this:

class SomeComponent extends React.Component {
    render() {
        return (
            <div>...</div>
        );
    }
}

SomeComponent.propTypes = {
    children: React.PropTypes.node,
    items: React.PropTypes.object
};

export default connect(
    (state, props) => ({
        items: state.items
    }),
    (dispatch) => ({
        fetchSomething: (title) => dispatch(Actions.fetchSomething())
    })
)(SomeComponent);

It works, but I have a pathological dislike of long boilerplate code, and defining the parameters of a component at the end of the file just doesn’t feel right. Ending up with twenty components all named “StartPage” didn’t exactly help with debugging either. Fortunately, it can be significantly improved by enabling some not yet standard javascript features.

Static properties

Adding the transform-class-properties babel plugin allows defining properties as well as methods on a class - perfect for propTypes, which I can move to a more visible position, and I no longer have to remember to update the class name in two places when I use the component as a template.

class SomeComponent extends React.Component {
    static propTypes = {
        children: React.PropTypes.node,
        items: React.PropTypes.object
    };
    render() {
        return (
            <div>...</div>
        );
    }
}

Decorators

Decorators are enabled with the transform-decorators-legacy plugin. The syntax below is equivalent to later calling connect()(SomeComponent), but the decorated class can now be exported directly, and the class name is only needed in one place.

@connect(mapStateToProps, mapDispatchToProps)
export default class SomeComponent extends React.Component {
    static propTypes = {
        children: React.PropTypes.node,
        items: React.PropTypes.object
    };
    render() {
        return (
            <div>...</div>
        );
    }
}

Much cleaner, though that does leave out the property mappings. To further simplify things, I ended up making a custom decorator that checks for a static method on the class before calling connect.

@page
export default class SomeComponent extends React.Component {
    static propTypes = {
        children: React.PropTypes.node,
        items: React.PropTypes.object
    };
    static mapStateToProps(state, props) { 
        return {
            items: state.items
        };
    }
    static mapDispatchToProps(dispatch) => {
        return {
            fetchSomething: (title) => dispatch(Actions.fetchSomething())
        };
    }
    render() {
        return (
            <div>...</div>
        );
    }
}

Ok, so technically this is the same length as the original, but it works much better when the code gets longer than a page, and no repeated renaming is needed when copying it as a new component. There’s also a lot of other common functionality that can be hidden in the decorator beyond the scope of this example - I’m not sure if a universal component extension makes sense yet, but certainly at the app level there is always a bunch of stuff that needs to be applied on every page.

Sharing Web Code with React Native

Tue, 13 Dec 2016 22:00:00 +0000

One of my current projects involves building much the same thing as both web and native apps. As a result, I have spent a fair bit of time thinking about how best to share code between the different platforms.

Front end logic

This is the easy one - Redux works out of the box with both React and React native. You just need to make sure the actions/reducers don’t directly do anything that won’t be shared. So far that seems to mostly be routing (react native uses a completely different navigation model) and web api calls - even if the app still calls the web api, the authentication process is completely different.

Data access

The final version of the app has quite different requirements for working with data - local storage is available, and the whole thing should work offline. Eventually I expect that only the interface connecting it to redux will be shared, but as a first step it turns out to be really useful to be able to use the web api as is. An important part of my development process is being able to use the app myself, and this lets me start using the app before writing any native code. The app isn’t releasable like this, but it feels like the real thing for testing. It also means that only one implementation is needed during early development when stuff is changing a lot.

Although I initially had the API set up as an ES6 module with exported functions, I’ve found the best approach to be a class that can be initialized in the non-shared entry point. It makes little difference for the final implementation, but makes early development much easier - initially only the url and authentication will be different, with more specialized implementations added gradually.

Splitting the API into multiple parts is probably useful here - most likely the app will need to continue connecting to some parts of the api after the core is implemented locally, so make sure it is easy to remove the login / connectivity handling for only half the api calls.

UI code

As far as I can tell, UI code is rarely shared between web and React Native apps. On a certain level this makes sense - native components usually look better - but it comes with some disadvantages as well. Building a full set of native components is a significant chunk of work before the app does anything, and keeping all platforms up to date can be challenging in the experimental stage of development.

My approach is to use the page level components from the web version as either final implementation or at least placeholders for the native pages. Redux makes it relatively easy to pipe property updates and actions through the webview bridge. The framework I set up for this, react-native-web-components, is available on github. It’s still somewhat a work in progress and has some limitations, but works well enough for now.

Navigation and page transitions stay as native code and are not shared - this covers 90% of the places where a hybrid app doesn’t look like a real native app, but requires minimal effort when all the pages use the same navbar component. In the past I have built apps using native transitions with cordova, but react-native makes it way easier to mix web and native components.

Differences in the overall app structure are somewhat inevitable anyway - login / connectivity ui in particular is completely different, with the web app requiring authentication on startup, and the native app needing authentication to be optional and only used for some functions.

Routing

Routing and app structure seem to be fundamentally unsharable. I am currently using react-router and react-native-router-flux, which are quite different, but I haven’t found any that are significantly more similar and I don’t really want to write my own. Web routes are based on a url for each page in the app, with the option to work out an appropriate transition based on link settings or the current route. Native routes are linked directly to a transition, and are not necessarily valid from all starting routes.

However, in most cases transitioning to a new page requires the same kind of input, so it was reasonably easy to set up a wrapper as part of react-native-web-components which converts a common redux action into an appropriate router action. So far the connection is one way - both routers offer some sort of bidirectional integration with redux, but that hasn’t seemed worthwhile to set up yet.

Project structure

My current setup involves three main git repos / npm packages:

app-client - a private npm package which contains most of the react / redux code. It can include some react-native components, but they must be sufficiently separate to not accidentally get imported into a web only package.
app-web - implements the server side api and hosts the web version of the app.
app-native - The native app. The only js code is in index.ios.js, which calls most of the same code from app-client but with different settings.

I usually use more pieces than that; I’d prefer to have a separate package for client code that is shared across multiple similar apps. However, the fact that the react packager doesn’t support npm link (or anything involving symlinks) makes that severely annoying. I have a watchman task that calls rsync to copy changes from app-client to app-native/node_modules/app-client, but it’s still annoying. I’m even considering using multiple targets rather than multiple app projects for some similar apps to further reduce the number of pieces.

What the internet won't tell you about setting up mongo replica sets

Sun, 10 Jan 2016 10:41:00 +0000

Over the last week or so I have been working on designing a simple autoscalable MongoDB cluster for hosting various projects. Seems like it should be easy, but a couple of details took way too much searching to figure out.

Single node replica sets

Common knowledge

A quick search turns up the fact that a replica set requires at least two servers and is entirely different from standalone mode. Tutorials on setting up a replica set typically start with setting up three empty servers then calling rs.initialize() with three addresses.

The truth

A replica set will work just fine with a single node.

Why everyone says you can’t

In normal operation, a single node replica set would be a bit silly - it uses more resources than standalone mode, but without the benefit of having a replacement server available, which is the whole point of replica sets.

Why it matters

Automating setup of the replica set is far easier if all nodes after the first are identical:

On server 1:

Call rs.initialize with only one node configured

On server 2..n

Connect to server 1
Call rs.add with own address

Even number of nodes

Common knowledge

There is no shortage of sources saying that a replica set should have an odd number of nodes, and that if you have an even number you need to add an arbiter to get back to odd numbers.

The truth

Having an even number of nodes will not cause any problems - The issue is not the possibility of deadlocked elections or something similarly catastrophic, but that adding a fourth server does not usually provide any value until you add the fifth.

Why everyone says you can’t

The primary purpose of a mongo replica set is to be able to tolerate failing servers. This only works when more than half the replica set survives the failure.

If you have two servers and one fails, there is no way to tell the difference between the primary failing (secondary should become primary) and the secondary becoming disconnected from a functioning primary (secondary should wait for reconnection). The cluster becomes read only, which is far better than potentially allowing both servers to think they are the survivor and start writing inconsistent data.

If you have 3 servers configured, you need 2 surviving servers to form a majority, so the replica set can survive a single server failing.

Add a fourth server, and you need three survivors to make a majority - you can still only tolerate a single failure.

Adding a fifth server to get back to odd numbers, the majority requirement stays at three, so you gain the ability to handle an additional server failing.

Note that the probablity of 2/4 servers failing is slightly higher than the probabilty of 2/3 servers failing, so technically you are worse off with four than with three. However, your individual servers would have to be extremely flaky for this to become a significant problem.

Why it matters

Scaling. My AWS setup treats all servers as disposable - they are never rebooted, only terminated and replaced. Deciding that there will normally be three servers in the cluster is easy. Ensuring that there will never be two or four is much harder.

Reducing friction

Sat, 05 Sep 2015 23:30:00 +0000

I always have too many projects on, and switching between them can be a problem. If I go back to a project I haven’t worked on in a while, I end up spending all the available time thinking things like “Is this really the same code as the live version?” and “How did I end up with ninety-three unpushed commits here?”

Reducing the number of projects is never likely to work for me, so clearly it is time to improve my development setup to make it all managable.

Switching between projects should be easy

Consistency is key here. It may not be possible to have everything work the same way, but I can come close.

I already have most things set up so that running gulp watch starts a development web server and automatically builds all changes. That can be extended to also start up a database or anything else that may be needed.

If I don’t have a development environment already set up, I should be able to get everything I need with just git clone and npm install, and maybe npm link if I’m working on dependencies at the same time. No custom database setup or environment variables I can never remember.

I should not have to think how to deploy a new version

This means everything on a CI server for a start. In some ways that would be enough, but since I don’t want to spend a lot of time setting up scripts for each project, they should all deploy the same way as much as possible.

Something like heroku with hosted mongodb would work for a lot of my projects, but other stuff is more experimental, and needs more than a basic web server and database. That should not require setting up a completely new system. Also, with a large number of small projects, hosting them seperately could get expensive.

A previous attempt involved setting up git deployment on an EC2 instance, but that meant dealing with complex git commit hooks and a puppet script that needed complicated updates for each new app. And only using it for a few projects made it easy to forget how it worked.

Shared autoscalable EC2 instances with CodeDeploy for individual apps looks like being a good solution, though I’ll need to make sure that after the initial setup it is no more effort to work with than a fully managed system.

Unreleased apps should be usable with real data

Actually using an app is by far the best way to test its usability.

I have tried a few different approaches to this in the past, none ideal. Connecting to the development server is fast and easy, but it means having local data that can’t be deleted. Having the dev server connect to an online database solves that, but having the session store thousands of miles away from the app server isn’t exactly great for performance. In either case, nothing works when not on the local network. Using the deployed version of the app solves that, but makes it harder to test the latest updates.

This time I’m going to try making my continuous deployment setup good enough that there are never any significant features missing from the deployed version - test isolated functionality locally with test data while writing code, but any actual use is on the live environment.

All environments should be disposable

Keeping any system working requires effort, so I’d rather not need to - in both development and live environments I should be able to delete everything and rebuild from scripts. My git folder should be a lot easier to navigate if it contains only active projects rather than everything I have worked on in the last few years.

Live environments do require keeping the database up, but with a sufficiently automated replica set, individual servers can be disposable. I should not have to think about managing server patches or fixing a failed server - if something goes wrong or an update is needed, just shut it down and start a new instance.

I have a couple of projects which store data on local disk, which doesn’t fit too well with this. I think I can replace that with NFS - still a single point of failure that has to be maintained, but at least it is kept separate from everything else and unlikely to need much management compared to a full web server.

Anything with authentication or certificate requirements becomes a bit challenging when you disallow manually entering a password or uploading certificates. For the live setup, an encrypted write only S3 bucket with IAM instance roles should work. That won’t help with a local development environment, but it may be possible to avoid the requirement altogether there.

Tests should be easy to set up

I know I should use more unit tests, but getting the first one in place tends to be enough effort that I don’t get around to it. Test setup definitely needs to be part of my standard project template - Something that says “0/0 tests passed” isn’t all that useful in itself, but changing it to “0/1” is very easy.

Including ESLint as part of the basic test setup is also a good idea - it catches a lot of errors for something that takes almost no effort to set up.

Reboot

Thu, 27 Aug 2015 08:46:00 +0000

It seems to have been a while since I updated my blog. No idea why.