Forem: Emilio Srougo

Dynamic imports in React-Native

Emilio Srougo — Thu, 14 Dec 2017 22:26:44 +0000

Have you ever tried to do this in a React-Native app?

<Image source={require("./images/" + this.props.image)} />

If you have, you probably discovered that all the imports are statically analyzed at compile-time, and have to be a simple string, not a dynamic expression.
Nevertheless, in a recent project this was very frustrating; My requirements were to include a folder of images in the app bundle, and render one of them according to a response from the server.
What we can do, is to require all the images in a file:

// assets/images/index.js
const images = {
  dog: require("./dog.png"),
  cat: require("./cat.png")
}
export default images;

Then, we can use it like this:

// app/imageView.js
import images from "../assets/images"
const View = (props) => 
  <Image source={images[this.props.image]} />

The problem is that my images folder had a lot of images I couldn’t possibly manually require them all.
So, I used the power of automation and created a simple script to make the assets/images/index.js file for me:

// prepareImages.js
const fs = require("fs");
const files = fs.readdirSync("./assets/images").filter(x => x.includes("png"));
const ex =
  "{\n" +
  files.map(x => `"${x.split(".png")[0]}": require("./${x}"),`).join("\n") +
  "}";
const res = "export default " + ex;
fs.writeFileSync("./assets/images/index.js", res);

This will produce a nice file exporting every image in a folder.
Thank you for reading!

P.S: I found a babel plugin that does something like this: https://github.com/dushaobindoudou/babel-plugin-require-all but the documentation isn’t very clear (is in Chinese or something) so I tested it, and here is how it works:
given: const imges = requireAll('./assets/imgs')
it will output:

const $assets_images_cat = require('./assets/images/cat.png');

const $assets_images_dog = require('./assets/images/dog.png');

const images = {
  $assets_images_cat: $assets_images_cat,
  $assets_images_dog: $assets_images_dog
};

Composable Object validations in JS

Emilio Srougo — Mon, 31 Jul 2017 02:34:01 +0000

“Bellas Artes” byÂ me

In my day job, I’m working in a project that consists of a react-native app that is flexible enough to be configured to the needs of many of our clients. A lot of that configuration comes from the server, at runtime. But we also need to configure a lot of things at compile time, mainly assets and variables needed in the native code.

For that end, we have a setup script that receives a configuration file in JSON and makes a bunch of side effects. I realized that if some of these things went wrong, it would silently and fatally affect the JS runtime. So, I decided to implement a validation function of the JSON config file before making any changes, to make sure each config field had the correct type.

I knew this would be complex, because some fields are optional, others are required but only if some other field is set, and so on.

Fortunately, found the perfect abstraction to make this easy and simple. I discovered Spected.

My first rules looked like this:

const isType = R.curry((type, value) => R.type(value) === type);
const rules = {
  version: [[isType('Number')], 'Version must be a number'],
  build: [[isType('Number')], 'Build must be a number'],
  appName: [[isType('String'), 'appName must be a string']]
}

As you can see, we are leveraging the power and Ramda and currying to make amazingly simple validations. But, of course, this is a simplified version. The real-world code had many more rules, and writing the same kind of message over and over again seemed like something I shouldn’t have to do.

If only I could pass Spected a function to make the error message… Such a function would receive the field name and the type it’s supposed to be and return a nice error message, like this:

const typeMessage = (type, field) => `${field} should be a ${type}`;

Looking at Spected source code, I discovered that the error message could already be a function, but it wasn’t passed the field name. So, I submitted a PR to make that happen, and _VoilÃ _! A whole new world of simple and super-composable validations started to appear!

const typeMessage = (type, field) => `${field} has to be a ${type}`;
const typeRule = type => [
  isType(type),
  (val, field) => typeMessage(type, field)
];
const isString = typeRule("String");
const isNumber = typeRule("Number")

const rules = {
  version: [isNumber],
  build: [isNumber],
  appName: [isString]
}

Now you should be convinced of the advantages of such an approach, but I’ll make my point stronger by writing about optional fields. If the config file is missing one of these fields, no problem. But If it’s present, we still want to make sure that the type is valid.

Because the validation function is just a function, we can make a higher-order function that takes the validation function and only runs it if the value is not null. Meet unlessNil:

const unlessNil = R.curry((f, val) => R.or(f(val), R.isNil(val)));

Now we can do this:

const optionalTypeRule = type => [
  unlessNil(isType(type)),
  (val, field) => `if ${field} is set, it must be a ${type}`
];
const validationRules = {
  appDescription: [optionalTypeRule('String')]
}

Of course, in order to do this, first the input object must be normalized, so all the missing fields are added with a null value. This can be done with a single function:

const normalize = (spec, input) =>
  Object.keys(spec).reduce(
    (acc, x) => R.assoc(x, R.propOr(null, x, input), acc),
    {}
  );

Awesome, right?

Now, I’ll go into more crazy stuff, keep reading if you are interested in making a field depend on another one!

So, let’s say that we have a configuration field notificationsClientId that is only required if the boolean field getsNotificationsis true

A curious fact is that the validation functions in Spected, also get the whole input object as the second argument. So I knew that something like this should be possible:

const validationRules = {
    notificationsClientId: [
    [
      dep("getsNotifications", R.equals(true), isType("String")),
      "If getsNotifications is true, notificationsClientId is required as a string"
    ]
  ]
}

As you can see, the dep function accepts three parameters:

the field that the current field is dependent on,
the function to run on said field,
and the function to run on the current field if the function in the second argument returns true

dep then returns a validation function ready to be used. It may sound complicated, but look at the implementation. It’s quite simple:

const dep = (field, cond, f) => (val, obj) =>
  cond(obj[field]) ? f(val) : true;

That’s it!

So, hopefully this will help you see some of the advantages of composition-friendly APIs and the functional paradigm in general.

Thank you for reading!

Implementing a Tiles View in React Native (a la iOS)

Emilio Srougo — Fri, 31 Mar 2017 18:36:11 +0000

I recently had a react-native project where a certain screen had the following requirements:

A screen with square tiles arranged with equal space among them.
The arrangement must always be from left to right (and look kind of like an iOS home screen).
The number of tiles per row must be configurable. The size and margin must be calculated accordingly.

This was one occasion where flex was clearly not enough, so after a lot of experimentation, I came up with the following formula:

// tpr = tiles per row
const calcTileDimensions = (deviceWidth, tpr) => {
  const margin = deviceWidth / (tpr * 10);
  const size = (deviceWidth - margin * (tpr * 2)) / tpr;
  return { size, margin };
};

This function, along with the right styles (which I'll show you) provides the expected results. Look at these images:

tpr = 3:
tpr = 2:

Here is a full usage example:

import React, { Component } from 'react';
import { Text, View, StyleSheet, Dimensions } from 'react-native';
const { width } = Dimensions.get("window");

export default class App extends Component {
  render() {
    const tileDimensions = calcTileDimensions(width, 2)  // -> change this number and see!
    const tiles = 'Lorem Ipsum Dolor Sit Amet'.split(' ')
    return (
      <View style={styles.container}>
        {tiles.map(i => Item({...tileDimensions, text: i}))}     
      </View>
    );
  }
}

const Item = ({size, margin, text}) => (
  <View style={[styles.item, {width: size, height: size, marginHorizontal: margin}]}>
    <Text style={styles.itemText}>{text}</Text>
  </View>
)

const calcTileDimensions = (deviceWidth, tpr) => {
  const margin = deviceWidth / (tpr * 10);
  const size = (deviceWidth - margin * (tpr * 2)) / tpr;
  return { size, margin };
};

const styles = StyleSheet.create({
  container: {
     justifyContent: "flex-start", flexDirection: "row", flexWrap: "wrap", marginTop: 30
  },
  item: {
    backgroundColor: 'yellow',  
     alignSelf: "flex-start",
     alignItems: 'center',
     justifyContent: 'center',
     marginBottom: 20
  },
  itemText: {
    fontSize: 20
  }
});

And, here it is as a Snack in Expo. Feel free to play around with it!
I hope you find this useful. Thanks for reading!

Rethinking Redux (and reducing its boilerplate)

Emilio Srougo — Wed, 29 Mar 2017 18:25:33 +0000

tl;dr: redux-create-module

Suppose you want to create a new module in your react-redux app.
You know the drill.
Create the action type constants, make and the action creators, and handle the types in the reducer.
You may have noticed that the process looks the same almost every time.
We, as developers, know that this kind of things could, and should be abstracted and automated.

So, first let's think what's the best solution for Developer Experience.
Or, since we are the Developers, let's just Rethink Redux.

Well, if we are only interested in mapping actions to states, my first thought is to make a Map. Or a regular object, for that matter.

const counterMap = {
  increment: (state) => state + 1,
  decrement: (state) => state -1
}
// How do we use it? Simple. With a reducer.
const reducer = (state = 0, action) => 
  (counterMap[action.type]) 
    ? counterMap[action.type](state) 
    : state

But we don't want to create the reducer. We only want to think about the Map. Let's make a function that takes a Map and returns a reducer

const createReducer = (initialState, map) =>
   (state = initialState, action) => 
     (map[action.type]) 
       ? map[action.type](state) 
       : state

const reducer = createReducer(0, counterMap)

reducer(0, {type: "increment"}) // => 1

So simple! Or, too simple! Because we have a problem here. Action creators were invented for a reason, and that's because some actions need to have a payload to be handled... Or is it?
No! of course, there is another reason and that's because it's unsafe and ineffective to pass strings to the reducer. What if we make a typo on it?!
So let's get more serious now.

We still don't want to create the action creators manually, and, why should we?
Think about it, createReducer already has all the information it needs to make them.
It can get the types of our actions from the keys of the Map.
So, let's make it return both, a reducer and the action creators, and name it createModule

const createModule = (initialState, map) => {
  const reducer = (state = initialState, action) => 
     (map[action.type]) 
       ? map[action.type](state) 
       : state
  const actions = Object.keys(map).reduce(
    (acc, type) =>
      Object.assign(acc, {
        [type]: (payload = {}) => ({ type, payload })
      }),
    {}
  );
}  
// example
const counterMap = {
  add: (state, {payload}) => state + payload
}
export const counter = createModule(0, counterMap)

// then somewhere in a connected component...
dispatch(counter.actions.add(2))

Neat!

Of course, we still have some todos. like namespacing our actions to avoid conflicts, and allowing a reducer to handle an action from another module.
But we won't get into that in this post.

Instead, I'll refer you to the source of the little module I made.

Thanks for reading!

Photo: Sunrise in the Sea by me :)