Forem: José Del Valle

React Native File Upload using GraphQL & Apollo

José Del Valle — Thu, 03 Sep 2020 00:00:00 +0000

It's been a couple of months since my last article. I've been pretty busy working on KnobsAI and haven't had much time to write.

I thought it would be nice to share how I implemented the file upload feature in KnobsAI so here's a short article on that.

Today I'll be showing how to upload pictures from a React Native app to Digital Ocean Storage, using GraphQL and Apollo.

While the example is pretty simple, it sets the ground for more complex stuff. The pictures will be uploaded to Digital Ocean Storage, which uses the AWS API, but you can apply the same logic to upload them to a different service.

If you are using Digital Ocean Storage, you'll need to:

I used the guide from the second link as a starting point for this feature. It doesn't use GraphQL tho, which is what I introduced in my project and today's guide.

Here's the repo with the source code in case you want to fork it.

Server-Side Architecture

The server side is comprised of three files: the index, the schema, and the storage.

In the index.js file, we define our ApolloServer and the Express app. If you've already worked with GraphQL you may have done this differently as there are many ways to do it. The important thing here is the Storage service that is being passed in the ApolloServer context so every resolver can make use of it.

const express = require('express');
const Storage = require('./storage');
const { ApolloServer } = require('apollo-server-express');
const { typeDefs, resolvers } = require('./schema');

const PORT = process.env.SERVER_PORT || 4000;

const app = express();

const server = new ApolloServer({
  typeDefs,
  resolvers,
  context: ({
    req,
    res,
  }) => ({
    req,
    res,
    Storage
  }),
  playground: {
    endpoint: `http://localhost:${PORT}/graphql`
  },
});

server.applyMiddleware({
  app
});

app.listen(PORT, () => {
  console.log(`Server listening on ${PORT}`);
})

The schema es where we define our mutation resolver that will receive the image object from the React Native app and pass it to the Storage service. As you can see, the Storage service is available via the context parameter because we injected it when setting up the server.

const {
  gql,
  GraphQLUpload
} = require('apollo-server-express');

const uploadSchema = gql`
  type Query {
    _empty: String
  }
  type Mutation {
    uploadImage(
      image: Upload
    ): String
  }
`

module.exports = {
  typeDefs: [uploadSchema],
  resolvers: {
    Upload: GraphQLUpload,
    Mutation: {
      uploadImage: async (root, { image }, {
        Storage
      }) => {
        const folder = `rn-upload/`;
        try {
          const uploadResult = await Storage.upload(image, folder);
          return uploadResult.uri;
        } catch(e) {
          return new Error(e);
        }
      },
    }
  }
};

The Storage service is responsible for communicating with the Digital Ocean Storage via the AWS API. Remember from the guide above, you need to store the access keys to your bucket in a .aws/credentials file.

An important thing to note here. The image property received in the resolver above is being sent using apollo-upload-client and it's an object containing a filename, a mime-type, the encoding, and a Read Stream.

The Read Stream is what we need to pass to the s3.upload function as the Body. It took me some time to figure this out as I was passing the entire file object

const aws = require('aws-sdk');
const { v4: uuid } = require('uuid');
const { extname } = require('path');

// Set S3 endpoint to DigitalOcean Spaces
const spacesEndpoint = new aws.Endpoint('nyc3.digitaloceanspaces.com');
const s3 = new aws.S3({
  endpoint: spacesEndpoint,
  params: {
    ACL: 'public-read',
    Bucket: 'your-bucket-name',
  },
});

async function upload(file, folder){

  if(!file) return null;

  const { createReadStream, filename, mimetype, encoding } = await file;

  try {
    const { Location } = await s3.upload({ 
      Body: createReadStream(),               
      Key: `${folder}${uuid()}${extname(filename)}`,  
      ContentType: mimetype                   
    }).promise();         

    return {
      filename,
      mimetype,
      encoding,
      uri: Location, 
    }; 
  } catch(e) {
    return { error: { msg: 'Error uploading file' }};
  }
}

module.exports = {
  upload,
};

Client-Side Architecture

As for the React Native side, the important thing here is integrating apollo-upload-client into the mix.We need to pass an upload link to our ApolloClient using createUploadLink.

Also, don't forget to put your computer's IP if you're running the app on a simulator/emulator, or whatever IP you're using to run the server app.

import React from 'react';
import { ApolloClient } from '@apollo/client';
import { InMemoryCache } from 'apollo-boost';
import { createUploadLink } from 'apollo-upload-client';
import { ApolloProvider } from '@apollo/react-hooks';
import ImageUploader from './ImageUploader';

// Use your computer's IP address if you're running the app in a simulator/emulator
// Or the IP address of the server you're running the node backend
const IP = '0.0.0.0'
const uri = `http://${IP}:4000/graphql`;

const client = new ApolloClient({
  link: createUploadLink({ uri }),
  cache: new InMemoryCache(),
});

export default function App() {

  return (
    <ApolloProvider client={client}>
      <ImageUploader />
    </ApolloProvider>
  );
}

If you happen to have several links you'd need to use ApolloLink.from as in the following example:

const client = new ApolloClient({
  link: ApolloLink.from([
    errorLink,
    requestLink,
    createUploadLink({ uri }),
  ]),
  cache: new InMemoryCache(),
});

We then have an ImageUploader component, which uses an ImagePicker to let you choose an image from the phone's gallery and then calls the uploadImage mutation. The important thing here is to use the ReactNativeFile constructor from the apollo-upload-client package which will generate the object with the Read Stream we discussed above.

Everything else is pretty much UI stuff like showing a loading spinner while the image is being uploaded and a status message when it fails or succeeds. If it succeeds it will display the URL where the image was uploaded.

import React, { useState, useEffect } from 'react';
import { StyleSheet, Button, View, Image, Text, ActivityIndicator } from 'react-native';
import Constants from 'expo-constants';
import * as ImagePicker from 'expo-image-picker';
import { gql } from 'apollo-boost';
import { useMutation } from '@apollo/react-hooks';
import { ReactNativeFile } from 'apollo-upload-client';
import * as mime from 'react-native-mime-types';

function generateRNFile(uri, name) {
  return uri ? new ReactNativeFile({
    uri,
    type: mime.lookup(uri) || 'image',
    name,
  }) : null;
}

const UPLOAD_IMAGE = gql`
  mutation uploadImage($image: Upload) {
    uploadImage(image: $image)
  }
`;

export default function App() {

  const [image, setImage] = useState(null);
  const [status, setStatus] = useState(null);
  const [uploadImage, { data, loading }] = useMutation(UPLOAD_IMAGE);

  useEffect(() => {
    (async () => {
      if (Constants.platform.ios) {
        const { status } = await ImagePicker.requestCameraRollPermissionsAsync();
        if (status !== 'granted') {
          alert('Sorry, we need camera roll permissions to make this work!');
        }
      }
    })();
  }, []);

  async function pickImage () {
    const result = await ImagePicker.launchImageLibraryAsync({
      allowsEditing: true,
      allowsMultipleSelection: false,
      aspect: [4, 3],
      quality: 1,
    });

    if (!result.cancelled) {
      setImage(result.uri);
    }
  };

  async function onUploadPress() {
    status && setStatus(null);
    const file = generateRNFile(image, `picture-${Date.now()}`);
    try {
      await uploadImage({
        variables: { image: file },
      });
      setStatus('Uploaded')
    } catch (e) {
      setStatus('Error')
    }
  }

  return (
    <View style={styles.container}>
      <Button title="Pick an image from camera roll" onPress={pickImage}/>
      {image && <Image source={{ uri: image }} style={{ width: 200, height: 200 }} />}
      {image && <Button title={ loading ? "Uploading" : "Upload"} onPress={onUploadPress} disabled={loading}/>}
      {
        loading && (
          <ActivityIndicator size="small" style={styles.loading}/>
        )
      }
      <Text style={{ color: status === 'Uploaded' ? 'green' : 'red'}}>{status}</Text>
      {
        status === 'Uploaded' && (
          <Text>URL: {data.uploadImage}</Text>
        )
      }
    </View>
  );
}

const styles = StyleSheet.create({
  container: {
    flex: 1,
    backgroundColor: '#fff',
    alignItems: 'center',
    justifyContent: 'center',
  },
  loading: {
    margin: 16,
  }
});

Now, this is a super simple example. You will most likely add more logic to this. Let's say, for example, a feature to let users change their profile picture. You'd need to wait for the Storage Service to give you the picture URL and then you'd modify that user in the database.

Here's how I'd do it:

changeUserPicture: async ( 
  _,
  {
    _id,
    picture
  }, {
    User,
    Storage
  }
) => {

  const user = await User.findOne({ _id }); 

  if(user) {
    try {
      const folder = `users/${user._id}/profile/`;
      const { uri } = await Storage.upload(picture, folder);

      user.picture = uri;
      const updatedUser = await user.save(); 

      return updatedUser;
    } catch(e) {
      console.log(e);
    }
  }

  return user;

},

That's pretty much it for today's article! I hope this was useful to you. Feel free to provide any feedback you like or reach out if you need help.

Once again, here's the repo with the source code in case you want to fork it.

Thanks for reading!

Building a Multi-Tenant React App. Part 3: Customizable Components

José Del Valle — Thu, 14 May 2020 00:00:00 +0000

Hello again! I've been quite busy lately and haven't been able to keep up with this series. Let's try to go back to where we were and keep building this app. I think this one's gonna be short. In case you haven't read the previous articles here they are:

Today I'm gonna talk about customizable components and how you can render client-specific stuff in the UI based on configuration. We already know how to render different routes for the different clients but what about different components and components that are flexible enough to look and feel different?

So, starting where we left off in the previous article. Client A shows a HomePage component in the root route whereas Client B shows a ProductPage component. Let's say Client A wants to show a list of products in the HomePage via some cards. Client B will show a featured product in the ProductPage and some cards below it for the related products.

These cards will look different for these clients but we'll use the same component. This component will receive some config from the server that will tell it how to look.

Adding the Card configuration

We'll add a new components node in our config objects, right next to the routes node. We don't want to nest the component configurations inside the routes configuration cause the entire config object could get pretty deep and the components don't care in which route they are.

The card for Client A will have a header, an image, a footer, and will show a title and description. For Client B it will not show the header.

This is how our config objects will look now:

[
  {
    "clientId": 1,
    "name": "Client A",
    "routes": {
      "home": {
        "path": "/",
        "component": "HomePage"
      },
      "product": {
        "path": "/product/:productId",
        "component": "ProductPage"
      }
    },
    "components": {
      "card": {
        "showHeader": true,
        "showImage": true,
        "showFooter": true
      }
    }
  },
  {
    "clientId": 2,
    "name": "Client B",
    "routes": {
      "home": {
        "path": "/",
        "component": "ProductPage"
      }
    },
    "components": {
      "card": {
        "showHeader": false,
        "showImage": true,
        "showFooter": true
      }
    }
  }
]

Creating the Config Context

So now we'll have components that will receive their configuration. It would be useful to use React's Context API so we can have our entire client configuration in one single place. It can then be accessed by any component that needs it.

We'll create a new folder inside src called context and will add a new file called Config.js with the following code:

import { createContext } from 'react';

const initialConfig = {
  name: "No name",
  routes: {},
  components: {}
};

const ConfigContext = createContext(initialConfig);

export default ConfigContext;

What we are doing here is creating a new empty context that will store our config object. We'll leave those values empty for now but this is the place where you would want to add default configuration properties in case they are missing in the config that comes from the backend.

Now in App.js we need to import this context. We also need to wrap the Routes component in a Config Context Provider, like so:

The value prop in ConfigContext.Provider will receive the config we got from the server. This config will now be accessible to any component down the tree that makes use of useContext to access...well...the config context.

The entire App.js file will now look like this:

import React, { useState, useEffect } from 'react';
import logo from './logo.svg';
import './App.css';
import { getConfig } from './services/config.service';
import Routes from './Routes';
import ConfigContext from './context/Config';

function App() {

  const [config, setConfig] = useState({ loading: true, data: {} });

  const { loading, data } = config;

  useEffect(() => {
    async function getConfigAsync(){
      const { data } = await getConfig();
      setConfig({ loading: false, data });
    }

    getConfigAsync();
  }
  , []);

  return (
    <div className="App">
      <div className="App-header">
          {
            loading && <img src={logo} className="App-logo" alt="logo" />
          }
          {
            data.error && <p>'Error getting config from server'</p>
          }
          <ConfigContext.Provider value={data}>
            <Routes routes={data.routes}/>
          </ConfigContext.Provider>
      </div>
    </div>
  );
}

export default App;

Implementing the Card Component

Now that we have our Config Context ready, we just have to start consuming it in our components. The Card component will use useContext to get access to it and will retrieve the card-specific configuration. It will render according to the variables in that configuration.

import React, { useContext } from 'react';
import ConfigContext from '../context/Config';

function Card({ title, description, img }) {

  const { components: { card }} = useContext(ConfigContext);
  const { showHeader, showImage, showFooter } = card;

  return (
    <div className="card-container">
      {
        showHeader && (
          <div className="card-header">
            <h4 className="card-title">
              {title}
            </h4>
          </div>
        )
      }
      {
        showImage && (
          <img className={!showHeader ? "card-image-rd" : "card-image"} src={img} alt="Card Img" height="240" width="320"/>
        )
      }
      {
        showFooter && (
          <div className="card-footer">
            <p className="card-description">
              {description}
            </p>
          </div>
        )
      }
    </div>
  );
}

export default Card;

I'll add the card styles at the end of the article so we can keep going with what's important.

The Card component will show or hide the header, footer, and image based on the configuration it receives from the context.

You can see that the Card component is receiving a title, a description, and an image from props. We have to define these somewhere and we also need to make use of this component. We'll go to the HomePage and ProductPage and add it there.

We'll add an array of items in our HomePage component. We'll loop through this array and return a card for each item. It will end up looking like this:

import React from 'react';
import Card from './Card';

const items = [
  {
    id: 'card1',
    title: 'First Card',
    description: 'Some boring description',
    img: "https://loremflickr.com/320/240/food?random=1"
  },
  {
    id: 'card2',
    title: 'Second Card',
    description: 'Some boring description',
    img: "https://loremflickr.com/320/240/food?random=2"
  },
  {
    id: 'card3',
    title: 'Third Card',
    description: 'Some boring description',
    img: "https://loremflickr.com/320/240/food?random=3"
  }
]

function HomePage({ items }) {

  return (
    <div>
      Welcome to the Home Page!
      <div className="cards-container">
        {
          items.map((item) => (
            <Card key={item.id} {...item} />
          ))
        }
      </div>
    </div>
  );
}

HomePage.defaultProps = {
  items
}

export default HomePage;

Normally, we'll receive those items from the server but we keep this simple for now.

As for the ProductPage we'll do something a little different. Let's say Client B decided to show a featured product more predominantly and some cards below it for the other products.

For this, we're still gonna have an array of items but one of them will have a featured flag set to true. We are gonna render the featured item above the other ones. The component will look something like this:

import React from 'react';
import Card from './Card';

const items = [
  {
    id: 'card0',
    title: 'Featured Product',
    description: 'Interesting description',
    img: "https://loremflickr.com/320/240/food?random=0",
    featured: true
  },
  {
    id: 'card1',
    title: 'First Card',
    description: 'Some boring description',
    img: "https://loremflickr.com/320/240/food?random=1"
  },
  {
    id: 'card2',
    title: 'Second Card',
    description: 'Some boring description',
    img: "https://loremflickr.com/320/240/food?random=2"
  },
  {
    id: 'card3',
    title: 'Third Card',
    description: 'Some boring description',
    img: "https://loremflickr.com/320/240/food?random=3"
  }
]

function ProductPage({ items }) {

  const featuredProduct = items.find((item) => item.featured === true);
  const relatedItems = items.filter((item) => !item.featured)

  return (
    <div>
      Welcome to the Product Page!
      <div className="featured-product">
        <div>
          <img className="featured-img" src={featuredProduct.img} alt="Featured Img" height="240" width="320"/>
        </div>
        <div className="featured-content">
          <h2>{featuredProduct.title}</h2>
          <p>{featuredProduct.description}</p>
        </div>
      </div>
      <div className="cards-container">
        {
          relatedItems.map((item) => (
            <Card key={item.id} {...item} />
          ))
        }
      </div>
    </div>
  );
}

ProductPage.defaultProps = {
  items
}

export default ProductPage;

So what we are doing is extracting the featured item and the rest of the items into separate variables so we can render them separately.

Now, before running the app to verify how all this looks, let's add some styles in index.css :

.cards-container {
  display: flex;
  margin: 20px 0;
}

.card-container {
  width: 320px;
  margin: 5px;
  background-color: white;
  color: black;
  border-radius: 20px;
  box-shadow: 0 3px 6px rgba(0,0,0,0.16), 0 3px 6px rgba(0,0,0,0.23);
}

.card-header, .card-footer {
  padding: 10px;
}

.card-title, .card-description {
  margin: 0;
}

.card-image-rd {
  border-top-left-radius: 20px;
  border-top-right-radius: 20px;
}

.card-description {
  font-size: 18px;
  text-align: left;
}

.featured-product {
  display: flex;
  margin-top: 20px;
  background-color: white;
  color: black;
  border-radius: 20px;
  height: 240px;
  box-shadow: 0 3px 6px rgba(0,0,0,0.16), 0 3px 6px rgba(0,0,0,0.23);
}

.featured-img {
  border-top-left-radius: 20px;
  border-bottom-left-radius: 20px;
}

.featured-content {
  padding: 10px;
  text-align: left;
}

Run the app

Just like in the other articles. We have to run the server in one terminal and each of the clients separately using the following commands:

npm run server

Then move to the client folder. Open two terminals here so you can run the two client instances:

REACT_APP_CLIENT_ID=1 npm start

And:

REACT_APP_CLIENT_ID=2 npm start

This is how Client A should look:

And this is how Client B should look:

And that's it! We now have a basic multi-tenant app that can render different routes and components based on configuration received from the backend. As I mentioned in the first article, the real world multi-tenancy project I worked in was a little bit more complex but the basic ideas and architecture remain.

This approach should be enough to work on a larger app and gives space to work in more customization. Any route and any component can be customizable following this approach. Remember, if you want to add default configuration you can do so where we created the Config Context in the initialConfig object. This way if there is a client that doesn't have any configuration coming from the backend you can rely on the defaults.

Here's the Github repo in case you want the whole project.

Stay tuned and thanks for reading!

Follow me on twitter: @jdelvx

How I'm currently testing my GraphQL Resolvers & Mongoose Operations

José Del Valle — Sun, 19 Apr 2020 01:00:03 +0000

Photo by Jorn Eriksen on Unsplash.

During the last couple of days, I've been doing some integration testing on my resolvers plus my mongoose operations.

I thought it would be nice to just share the code. If anyone has some feedback or would like to suggest a different approach feel free to do so.

I'm using Jest as the test runner. I added this simple config so it doesn't complain cause I'm on Node instead of the client-side:

module.exports = {
  testEnvironment: 'node'
};

Here's my test script in package.json

"test": "env-cmd -e test -r ./.env-cmdrc.json jest",

I use env-cmd to manage my environment variables but this can also be as simple as:

"test": "jest",

Then I have a setup file where I create the test server using apollo-server-testing. I also import the graphql resolvers and typedefs, and my mongoose models to pass in the context function of the Apollo Server.

Then I also have some simple functions to connect, disconnect and drop the test DB. The MONGO_URI env variable just points to a test DB that is created before the tests and dropped when they're done.

const { createTestClient } = require('apollo-server-testing');
const { ApolloServer } = require('apollo-server-express');
const mongoose = require('mongoose');

const {
  typeDefs,
  resolvers
} = require('../schema');
const Device = require('../models/Device');
const DeviceSetting = require('../models/DeviceSetting');


const connectToDb = async () => {
  await mongoose.connect(process.env.MONGO_URI, 
    { useNewUrlParser: true, useUnifiedTopology: true }).catch(error => console.error(error));;
}

const dropTestDb = async () => {
  if(process.env.NODE_ENV === 'test'){
    await mongoose.connection.db.dropDatabase().catch(error => console.error(error));;
  }
}

const closeDbConnection = async () => {
  await mongoose.connection.close().catch(error => console.error(error));;
}


const server = new ApolloServer({
  typeDefs,
  resolvers,
  context: ({
    req,
    res
  }) => ({
    req,
    res,
    Device,
    DeviceSetting,
  }),
});

module.exports = {
  testClient: createTestClient(server),
  connectToDb,
  closeDbConnection,
  dropTestDb
}

And here are my tests. I'm currently testing all the CRUD operations, such as add, get, get all, update and delete. I do some snapshot testing but not for every case. The tests are somewhat dependant on the previous ones so that's why I store some ids to use them in further tests:

const { gql } = require('apollo-server-express');
const { testClient, connectToDb, dropTestDb, closeDbConnection } = require('../__testSetup__/setup');
const { ObjectId } = require('mongodb');

const { query, mutate } = testClient;

beforeAll(async () => {
  await connectToDb()
  await dropTestDb()
});

afterAll(async () => {
  await dropTestDb()
  await closeDbConnection()
});

describe("Device Resolvers", () => {

  const user = "5e9affa8d8f5db0461906ac7";
  let deviceId = '';

  it("Add Device", async () => {
    const ADD_DEVICE = gql`
      mutation addDevice( $user: ID!, $model: String, $brand: String, $description: String, $image: String) {
        addDevice(user: $user, model: $model, brand: $brand, description: $description, image: $image) {
          user
          model
          brand
          description
          image
        }
      }
    `
    const device = { 
      user,
      model: "Model name",
      brand: "The Brand",
      description: "Description",
      image: "url/to/image"
    }

    const { data } = await mutate({
      mutation: ADD_DEVICE,
      variables: { 
        ...device
      }
    })

    expect(data).toEqual({
      addDevice: {
        ...device
      }
    });

  });

  it("Get User Devices", async () => {
    const GET_USER_DEVICES = gql`
      query getUserDevices($user: ID!) {
        getUserDevices(user: $user) {
          _id
          user
          model
          brand
          description
          likes
          image
        }
      }
    `
    const { data } = await query({
      mutation: GET_USER_DEVICES,
      variables: { 
        user
      }
    });

    const { getUserDevices } = data;

    const expectedDevices = getUserDevices.map(device => {
      const { _id, ...rest } = device;
      expect(ObjectId.isValid(_id)).toEqual(true);
      expect(ObjectId.isValid(rest.user)).toEqual(true);
      return rest;
    })

    expect(expectedDevices).toMatchSnapshot();

    deviceId = getUserDevices[0]._id

  });

  it("Get Device", async () => {
    const GET_DEVICE = gql`
      query getDevice($_id: ID!) {
        getDevice(_id: $_id) {
          _id
          user
          model
          brand
          description
          likes
          image
        }
      }
    `

    const { data } = await query({
      mutation: GET_DEVICE,
      variables: { 
        _id: deviceId
      }
    })

    expect(ObjectId.isValid(data.getDevice._id)).toEqual(true);
    expect(ObjectId.isValid(data.getDevice.user)).toEqual(true);

    const { _id, ...rest } = data.getDevice;
    expect(rest).toMatchSnapshot();
  });

  it("Update Device Info", async () => {

    const UPDATE_DEVICE_INFO = gql`
      mutation updateDeviceInfo($_id: ID!, $model: String, $brand: String, $description: String, $image: String) {
        updateDeviceInfo(_id: $_id, model: $model, brand: $brand, description: $description, image: $image) {
          user
          model
          brand
          description
          image
        }
      }
    `
    const newInfo = { 
      _id: deviceId,
      model: "Updated model name",
      brand: "Another Brand",
      description: "Another Description",
      image: "url/to/image/2"
    }

    const { data } = await mutate({
      mutation: UPDATE_DEVICE_INFO,
      variables: { 
        ...newInfo
      }
    });

    const { _id, ...info } = data.updateDeviceInfo;

    expect(data).toEqual({
      updateDeviceInfo: {
        user,
        ...info
      }
    });

  });

  it("Delete Device", async () => {

    const DELETE_DEVICE = gql`
      mutation deleteDevice($_id: ID!) {
        deleteDevice(_id: $_id) {
          _id
        }
      }
    `

    const { data } = await mutate({
      mutation: DELETE_DEVICE,
      variables: { 
        _id: deviceId
      }
    });

    expect(data).toEqual({
      deleteDevice: {
        _id: deviceId
      }
    });

  });

});

So, as you can see. This is just like doing queries and mutations as you would normally do in the app. Maybe extracting the gql definitions would make this cleaner.

What I want to test here is primarily that everything is being stored, retrieved, updated and deleted to and from the database. Also that the results of these operations are good.

This is the first time I'm doing integration tests on this particular stack so any feedback is more than welcome.

I hope this was useful and thanks for reading!

Follow me on twitter: @jdelvx

Building a Multi-Tenant React App. Part 2: Dynamic Routes

José Del Valle — Wed, 15 Apr 2020 14:21:00 +0000

Hello! Welcome to the second part of my Multi-Tenant React App series. In the first part we took a look at how to set up the project and implemented some simple multi-tenancy features.

This series is inspired in a real-world problem that I faced a couple of years ago -although a bit more complex than this-. My team and I had to develop a multi-tenant app that could look and behave differently based con client-specific configuration coming from the API. Still, most of the layout, styles, and features would be the same for all the clients.

Imagine now that Client A wants to have a home page in their root route that will show a list of their products, whereas Client B wants to show a featured product page in their root route. Both clients want an about page and didn't request any custom look or feature in it.

This would mean two very different components to show in the root route and one common component for the about.

Let's leverage our current architecture to accomplish this.

Adding the routes configuration

First, we are gonna add some new config to our JSON database. Each client will have its own set of custom routes and the client side will render them accordingly.



[
  {
    "clientId": 1,
    "name": "Client A",
    "routes": {
      "home": {
        "path": "/",
        "component": "HomePage"
      },
      "product": {
        "path": "/product/:productId",
        "component": "ProductPage"
      }
    }
  },
  {
    "clientId": 2,
    "name": "Client B",
    "routes": {
      "home": {
        "path": "/",
        "component": "ProductPage"
      }
    }
  }
]

So, we've added a new routes object, each of its nodes will be specific to a route.

Implementing React Router

We will need to install react-router-dom in our client-side so we can handle these routes. Open the terminal and go to the client folder and execute the following command:



npm i react-router-dom

We are now gonna create a new component called Routes which will use react-router. This component will receive the routes config object we added to the database, will iterate through them and render their respective Route components.



import React from 'react';
import {
  BrowserRouter as Router,
  Switch,
  Route,
} from "react-router-dom";

function Routes({ routes }) {

  return (
    <Router>
      <Switch>
        {
          Object.keys(routes).map((key) => {
            const route = routes[key];
            return (
              <Route 
                key={`route-${route.path}`}
                path={route.path}
                exact>
                  <div>
                    {route.component}
                  </div>
              </Route>
            )
          })
        }
      </Switch>
    </Router>
  );
}

Routes.defaultProps = {
  routes: []
}

export default Routes;

So, instead of hardcoding our Route components, we render them dynamically based on what we receive in the routes config.See that I've set the routes prop as an empty array in Routes.defaultProps so it doesn't crash if we don't receive any routes from the server. We'll use this later to define a set of default routes.

Another important thing to consider for now is that we are not rendering any actual component in these routes, just the component name so we can test this before moving on.

Now, let's go to the App component and implement the Routes component we just created. I've made some changes to the JSX and will now show the react logo while waiting for the config objects. If the request is successful our Routes component will receive the routes config and render the routes as expected.

The App component will now look something like this:



import React, { useState, useEffect } from 'react';
import logo from './logo.svg';
import './App.css';
import { getConfig } from './services/config.service';
import Routes from './Routes';

function App() {


  const [config, setConfig] = useState({ loading: true, data: {} });
  const { loading, data } = config;

  useEffect(() => {
    async function getConfigAsync(){
      const { data } = await getConfig();
      setConfig({ data });
    }

    getConfigAsync();
  }
  , []);

  return (
    <div className="App">
      <header className="App-header">
          {
            loading && <img src={logo} className="App-logo" alt="logo" />
          }
          {
            data.error && <p>'Error getting config from server'</p>
          }

          <Routes routes={data.routes}/>
      </header>
    </div>
  );
}

export default App;

Ok, let's go and run the server and two client-side instances so we can test the two different configurations. Client A should show "HomePage" on the root route and Client B should show "ProductPage" for that same route.

In the project root folder let's do:



npm run server

And then move to the client folder. Open two terminals here so you can run the two client instances:



REACT_APP_CLIENT_ID=1 npm start

And:



REACT_APP_CLIENT_ID=2 npm start

You should see the following screen for Client A :

And this one for Client B :

Rendering components dynamically

So, now that we are rendering the routes correctly we need to add an object in the client-side that will map a component name like HomePage and ProductPage to an actual component.

Let's add these two new components first. Create a components folder next to App.js and add the following code. We'll keep them simple for now:

HomePage.js



import React from 'react';

function HomePage() {

  return (
    <div>
      Welcome to the Home Page!
    </div>
  );
}

export default HomePage;

ProductPage.js



import React from 'react';

function ProductPage() {

  return (
    <div>
      Welcome to the Product Page!
    </div>
  );
}

export default ProductPage;

We now need to add an object that will map the component name we have in the config object with the real component. Right here in the components folder, add a componentMapper.js file with the following code:



import HomePage from './HomePage';
import ProductPage from './ProductPage';

const COMPONENTS = {
  'HomePage': HomePage,
  'ProductPage': ProductPage
}

export default COMPONENTS;

We are now gonna use this mapper in our Routes component so each route renders its specific component.

Let's import the COMPONENTS map in the Routes and do some quick changes in the render function. We have to get the component from the map and then render it inside the Route component, like so:



import React from 'react';
import {
  BrowserRouter as Router,
  Switch,
  Route,
} from "react-router-dom";
import COMPONENTS from './components/componentMapper';

function Routes({ routes }) {

  return (
    <Router>
      <Switch>
        {
          Object.keys(routes).map((key) => {
            const route = routes[key];
            const Component = COMPONENTS[route.component];
            return (
              <Route 
                key={`route-${route.path}`}
                path={route.path}
                exact>
                  <Component />
              </Route>
            )
          })
        }
      </Switch>
    </Router>
  );
}

Routes.defaultProps = {
  routes: []
}

export default Routes;

You should see the following screen for Client A :

And this one for Client B :

Default Routes

As the last step for today's post, we'll add support for default routes. This means that there will be routes that are common among clients. We'll have a set of default or common routes in our client-side so they don't have to be added for all the clients in their config objects.

We will need to add a DEFAULT_ROUTES object in our Routes component:



const DEFAULT_ROUTES = {
  about: {
    path: "/about",
    component: "AboutPage"
  },
}

And set them as the default value for the routes prop in Routes.defaultProps :



Routes.defaultProps = {
  routes: DEFAULT_ROUTES
}

But this is not enough if we want to include the about route along with the custom ones, we have to merge both objects, the custom one from the config and the default one. I'll also add a simple navigation menu so we can go to the About page. The Routes component will end up being something like this:



import React from 'react';
import {
  BrowserRouter as Router,
  Switch,
  Route,
  NavLink
} from "react-router-dom";
import COMPONENTS from './components/componentMapper';

const DEFAULT_ROUTES = {
  about: {
    path: "/about",
    component: "AboutPage"
  },
}

function Routes({ routes: customRoutes }) {

  // We'll now call the routes prop as customRoutes inside the component.
  // Merge customRoutes with the default ones.
  const routes = {...customRoutes, ...DEFAULT_ROUTES};

  return (
    <Router>
      <nav>
        <ul>
          <li>
            <NavLink to="/" activeClassName='active' exact>Home</NavLink>
          </li>
          <li>
            <NavLink to="/about" activeClassName='active' exact>About</NavLink>
          </li>
        </ul>
      </nav>
      <Switch>
        {
          Object.keys(routes).map((key) => {
            const route = routes[key];
            const Component = COMPONENTS[route.component];
            return (
              <Route 
                key={`route-${route.path}`}
                exact
                path={route.path}>
                  <Component />
              </Route>
            )
          })
        }
      </Switch>
    </Router>
  );
}

Routes.defaultProps = {
  routes: DEFAULT_ROUTES
}

export default Routes;

I added the following styles to index.css so the Nav Bar would look OK:



.nav-bar {
  width: 100%;
  position: fixed;
  top: 0;
}

.nav-bar ul {
  list-style-type: none;
  margin: 0;
  padding: 15px;
  display: flex;
  justify-content: flex-end;
}

.nav-bar ul li {
  margin: 10px;
}

.nav-bar ul li a{
  text-decoration: none;
  color: white;
}

.nav-bar ul li a.active{
  color: cornflowerblue;
}

Cool! So, now you should be able to navigate between routes and the About page will be available for both clients.If we wanted to show custom information for each client in the About page we would need to fetch that from the server but we'll leave it as is for now. Remember that for client B the Home route shows the ProductPage instead of the HomePage component.

That's all for now! We've now covered custom routes but we still have to cover customizable components based on the config. I'll leave that for the next post.

Here's the Github repo in case you want the whole project.

Stay tuned and thanks for reading!

Follow me on twitter: @jdelvx

Building a Multi-Tenant React App. Part 1: Setup

José Del Valle — Tue, 31 Mar 2020 00:00:00 +0000

Before getting into today's post, I am offering free sessions to React beginners. Wanna participate? You just have to follow me on Twitter and DM me telling your experience, what do you like about React or Web Dev in general and your goals as a Web Dev. More info here.

Real-world scenario (cause it happened to me).

You work for a company that offers websites to different clients so they can showcase their products. All these websites share the same layout, the same core features and most of the components. There is some degree of flexibility allowed. For example, clients can choose the color theme and which routes to enable or disable. They can also choose which page or component to show on each route. Of course each client will have different content on their website.

The decision made is to only build one web application, flexible enough to handle these use cases instead of working on custom websites for each client. Clients are aware they'll share the layout and most of the styles.

In the end, we had about eight different clients. Two of them had two different sites. Each with a different color theme. We also ended up offering two different layouts and in some cases different components -some clients wanted very specific functionalities-.

How did we handle that? We received the client-specific configuration from the API and rendered everything dynamically client-side. Today I'll cover the project setup so we start with a good base. In future posts, I'll explain how we got to manage custom themes, custom routes, and custom components as per the clients' requests.

Initializing the project

Let's first create our folder structure and our client-side app. I created a folder called multi-tenant-react-app. Let's open the terminal, go to this folder and do npm init. It will ask you to type some info. Here's what I entered -the git repo is the one I'm gonna use for this series so you can leave this blank or add a repo of yours, I also called the entry point server.js instead of index.js-.

package name: (multi-tenant-react-app) 
version: (1.0.0) 
description: A multi tenant React app with server
entry point: (index.js) server.js
test command: 
git repository: (https://github.com/dlvx/multi-tenant-react-app.git) 
keywords: 
author: José Del Valle
license: (ISC)

Inside this same folder, we have to create our server.js file and initialize our react app with create-react-app. I'm gonna call it client because we are also going to work on a simple server using Node.

npx create-react-app client

We should end up with the following structure:

- multi-tenant-react-app
  - /client
  - server.js

Remember server.js is outside of the client folder.

Creating a basic server

Our server will serve the different config files to our client app so it knows what to render. For now, we'll install express to help us serve these config files. We are also gonna install the cors and nodemon packages. Make sure you're still in your root directory and do:

npm install express cors

You can choose to install nodemon globally or as a dev dependency. I have it globally.

npm install -g nodemon

Lets now add the script to run our server in the package.json file. Add the following line inside the scripts section:

"server": "nodemon server.js",

Ok, let's now code our server. We first have to set it up so it listens on a specific port and also accepts requests from another origin as we'll run our React development server on a different port.

const express = require('express');
const cors = require('cors');

// Setup
const PORT = process.env.SERVER_PORT || 4000;
const app = express();
app.use(cors());

// Routes
app.get('/getConfig', async function (req, res) {
  const { clientId } = req.query;
  /**
   * 
   * We'll add more code here later
   * 
  **/
});

// Run server
app.listen(PORT, () => {
  console.log(`Server listening on ${PORT}`);
});

We've added an endpoint called getConfig which will receive the client id from our react app and will return the config file specific to that client. For now, we're gonna handle the client id in our React app using environment variables but I'll return to that in a bit.

In the real world, we were storing the client configurations in a database but for this tutorial, I'm gonna stick with JSON just so you get the idea.

Let's create our JSON database now. Add a new folder called db , at the root level. Inside it lets add a file called configs.json. We should end up with the following structure:

- multi-tenant-react-app
  - /client
  - /db
    - configs.json
  - server.js

We'll now add some configuration for our clients in the configs.json file. Something simple for now so we can test this soon:

[
  {
    "clientId": 1,
    "name": "Client A"
  },
  {
    "clientId": 1,
    "name": "Client B"
  }
]

Serving client-specific configuration

Now, to serve each client configuration we need a way to get it from our JSON database and return it to the client-side app.

Let's add a new folder at the root level called model and create a new file inside it called config.model.js. For now, we'll add a simple function that will find the client config given an id:

const configs = require('../db/configs.json');

function getClientConfig(clientId) {
  return configs.find(config => config.clientId == clientId);
}

module.exports = {
  getClientConfig
}

Now, in our server.js we'll import this model so we can use it in our getConfig endpoint.

const Config = require('./model/config.model');

The getConfig endpoint will now look something like this:

app.get('/getConfig', async function (req, res) {
  // Receive the clientId from our client-side app
  const { clientId } = req.query;

  // Find the config for that particular clientId
  const clientConfig = Config.getClientConfig(clientId);

  if(!clientConfig){
    // Return an error if it's not found
    res.status(404).send({ error: `Config not found for this clientId: ${clientId}` });
  }

  // Send the config if found
  res.send(clientConfig);
});

We are now ready to communicate with the client-side app and send the config it needs.

Lets finally move to our React app.

Receiving the configuration in our React app

Go back to the terminal again and move to the client folder. Lets first run our app to make sure everything was set up correctly:

cd client && npm start

You should be able to see create-react-app's default home screen.

If everything's ok, let's install axios which will help us make requests to our server:

npm install axios

We need to create a new folder and some files. Create a folder called services and two files inside: axiosSetup.js and config.service.js.

Here's what we need to put in axiosSetup.js :

import axios from 'axios';

const instance = axios.create({
  baseURL: `http://localhost:4000`,
});

export default instance;

Basically, we're just creating an instance that will communicate with our server running on port 4000. We export this instance so we can re-use it in our services.

As for config.service.js we need to add the function that will make the GET request through the axios instance:

import axiosInstance from './axiosSetup';

async function getConfig(){
  try {
    return await axiosInstance.get('/getConfig', {
      params: {
        clientId: process.env.REACT_APP_CLIENT_ID
      }
    });
  } catch(e){
    return e.response;
  }
}

export {
  getConfig
}

We export the getConfig function so we can use it in App.js. As you can see, I'm sending the clientId to the server so it can find the correct config in the DB.

In production we didn't use environment variables to set the client id in the client-side but for the sake of the tutorial, it is just simpler this way.

One last step now. Lets go to App.js and import the getConfig service:

import { getConfig } from './services/config.service';

Besides that, we need to import the useEffect and useState hooks, so your first line would be something like this:

import React, { useState, useEffect } from 'react';

Inside our App component, we'll make use of useEffect to call getConfig when the component initially mounts and we'll use useState to manage our response status and store the config when available.

As for the JSX, we'll get rid of some things and add some status messages. It will show the name we set in each client config in our DB if the response is successful.

Our component will end up being like this:

import React, { useState, useEffect } from 'react';
import logo from './logo.svg';
import './App.css';
import { getConfig } from './services/config.service';

function App() {

  const [config, setConfig] = useState({ loading: true, data: {} });
  const { loading, data } = config;

  useEffect(() => {
    async function getConfigAsync(){
      const { data } = await getConfig();
      setConfig({ data });
    }

    getConfigAsync();
  }
  , []);

  return (
    <div className="App">
      <header className="App-header">
        <img src={logo} className="App-logo" alt="logo" />
        <p>
          {
            loading && 'Getting config from server...'
          }
          {
            data.error && 'Error getting config from server'
          }
          {
            data.name && `The client is: ${data.name}`
          }
        </p>
      </header>
    </div>
  );
}

export default App;

Let's try this out!

We can finally run our app! Make sure you're still in the client folder.

We'll first test our error scenario. Let's just run the following command without setting a client id:

npm start

If everything was set correctly and the React app can communicate properly with the server you'll see the following message:

Error getting config from server.

It failed cause we didn't set a client id in the environment variables so the server didn't find the config for this app.

Now, stop the app and add the client id to the environment variables and run the app again with the following command. Like so:

REACT_APP_CLIENT_ID=1 npm start

What do you get? I hope you see the message: The client is: Client A

Now, what if you set the client id to 2 and run the following?

REACT_APP_CLIENT_ID=2 npm start

You should see: The client is: Client B

You can run both client apps simultaneously if you set a different port for one of them, for example:

REACT_APP_CLIENT_ID=1 npm start

and

PORT=3002 REACT_APP_CLIENT_ID=2 npm start

Both will communicate with the same server and will receive their specific config.

Ok! We're finally done for the moment. This is just the tip of the iceberg. We've only shown the client's name! In the next posts, we'll see how we can have different routes per client and then different component configurations.

Here's the Github repo in case you want the whole project.

Stay tuned and thanks for reading!

Follow me on twitter: @jdelvx

I am offering free online sessions to React beginners

José Del Valle — Mon, 30 Mar 2020 17:29:21 +0000

Hello all!

So I’m giving away free online sessions to React beginners to provide some guidance.

I’ve been working with React and related technologies for 4+ years. The related technologies include Redux, GraphQL/Apollo, Webpack, Sass, and many more.

I used to be an interviewer at my previous job so I got the chance to interview around 100 devs. The interviews mostly covered topics from Javascript, React and Web Dev in general.

I’ll give away one session to 3 different people. Each session will include a mock interview and a Q&A section.

If you want to participate just follow me on Twitter and DM me telling your experience, what do you like about React or Web Dev in general and your goals as a Web Dev. Don’t forget to put a link to your blog or profile from StackOverflow, GitHub or dev.to.

I’ll announce the 3 winners on Tuesday, April 7th and will DM each so we can schedule the session.

Why am I doing this? Well, now that we are spending more time at home due to COVID-19 I just thought it would be nice to chat with other devs, provide some help, do some networking, and also learn from them as well. This way we fight the isolation and create new connections.

Looking forward to meeting you.

Thanks!

Svelte from a React developer's perspective. Part 4: Logic

José Del Valle — Sat, 28 Mar 2020 00:00:00 +0000

Hello again! This is the fourth post where I explore Svelte from a React developer's perspective. You can check out the previous posts in the links below:

Before I start talking about today's topic, I just want to write about my thoughts on what's going on in the world regarding COVID-19. Since my last article things have gotten pretty serious in some countries. We, as software developers may be a little luckier than other people cause we can most likely WFH. Still, we have to follow the advice given by the health authorities so we can help stop spreading the virus. You may not get seriously ill if you are young and healthy but think about the people that could get bad like the elders or people with special health conditions. Let's follow the best practices on this and help solve this bug 👍.

In today's post, I'm taking a look at logic and how Svelte compares with React in that matter.

When we think about logic, what first comes to mind are the if/else blocks.

Let's check them out:

If/Else Blocks

Svelte introduces some special syntax to let us declare these blocks inside our markup. A bit similar to React were we can put some Javascript code inside our JSX using curly brackets.

This is very simple and the code explains by itself:

<script>
  let x = 7;
</script>

{#if x > 10}
  <p>{x} is greater than 10</p>
{:else if 5 > x}
  <p>{x} is less than 5</p>
{:else}
  <p>{x} is between 5 and 10</p>
{/if}

As you can see in the example above, you can use the variable x inside these blocks, having x defined in your script section.

The only things you have to remember here are that the # character indicates a block opening tag, the / character indicates a block closing tag and the : character, as in {:else}, indicates a block continuation tag.

Think of this like just doing your normal if/else blocks from Javascript with some slightly different syntax.

Each Blocks

Iterating over arrays or array-like structures will always be a requirement when working in web applications. In React we use Javascript functions such as map() or forEach(). Svelte's logic does not go far from this. The following code shows us the way of iterating over an array and generating a list item element for each item in the array.

<script>
  let books = [
    { id: 'book_1', name: '1984', author: 'George Orwell' },
    { id: 'book_2', name: 'The Art of War', author: 'Sun Tzu' },
    { id: 'book_3', name: 'The Shinning', author: 'Stephen King' }
  ];
</script>

<h1>Books I really like</h1>

<ul>
  {#each books as book, i}
    <li><a target="_blank" href="https://www.bookstore.com/{book.id}">
      {i + 1}: {book.name} by {book.author}
    </a></li>
  {/each}
</ul>

As you can see, we are iterating over the books array, calling each item as book and also receiving the current index as i. We can then use the variables book and i inside our list item element.

Await blocks

It is very common on web applications to make asynchronous calls. Most likely to fetch some data from a remote server. The usual approach to dealing with this is showing some loading message by default while we get our response.

The way I am used to doing this in React is managing some variables in the state that will let me know if the request is pending and if it succeeded or failed. Then in my JSX I would usually validate against these variables to determine which UI element to render. There are libraries to handle this with less code but the approach is the same.

Svelte works in a similar way and lets us declare some await blocks in our markup. We have to specify the promise we are waiting for and our then and catch blocks if needed.

If you are familiar with Promises and Async Functions you should be able to get this right away.

Let's take a look at the following example from the tutorial with some comments I added:

<script>
  // This is the promise we are gonna await
  // In this example, we are calling getRandomNumber from the beginning
  // But this doesn't have to be this way if you want to call it on demand.
  // The variable promise will get what getRandomNumber returns once it resolves
  let promise = getRandomNumber();

  async function getRandomNumber() {
    // Here are some async operations, meaning that we won't get
    // the data right away. Let's say the random number comes from
    // a remote server.
    const res = await fetch(`tutorial/random-number`);
    const text = await res.text();

    // This is what we'll get in our markup once the promise resolves or fails
    if (res.ok) {
      return text;
    } else {
      // We can catch this error in our markup
      throw new Error(text);
    }
  }

  function handleClick() {
    // Promise will get what getRandomNumber returns once it resolves
    promise = getRandomNumber();
  }
</script>

<button on:click={handleClick}>
  generate random number
</button>

<!-- We'll show some ...waiting message while the promise resolves -->
{#await promise}
  <p>...waiting</p>
<!-- If the promise succeeds we show the result -->
{:then number}
  <p>The number is {number}</p>
<!-- We catch any error the promise could return -->
{:catch error}
  <p style="color: red">{error.message}</p>
{/await}

Not so different right?

Svelte has shown us that while it introduces some new syntax, it is all very similar to what we are used to. If you've worked with React or just know some Javascript you won't have serious problems getting into all this.

This is all for the fourth part. I have decided that I'll change the approach of this series and instead of going through the topics one by one I'll start working on a small Svelte app. Hopefully with several components and some data fetching. This way I'll be able to work with more realistic scenarios and get a better perspective of the framework. I'll try to get something cool in a couple of weeks!

Thanks for reading and stay tuned!

Follow me on twitter: @jdelvx

Svelte from a React developer's perspective. Part 3: Events

José Del Valle — Mon, 02 Mar 2020 00:00:00 +0000

Hello, this is the third article where I explore Svelte from a React developer's perspective. The previous articles discussed The Basics and the topics of Reactivity and Props.

In this article I'm gonna take a look at how Svelte manages events and just like the previous articles, I'll provide some quick comparisons to React.

Today's topics introduce some new syntax and approaches that a React dev may not be used to. However, Svelte has kept all these things simple enough for us to get them real quick. The best part of all is that it's still just Javascript.

Let's now talk about:

Events

We saw some events going on in previous articles. Any Javascript dev familiarized with DOM events, event handling, and event dispatching will feel comfortable with how Svelte does all this.

As seen before, the way you attach event handlers to DOM elements is by sticking the on: prefix right before the event name.

Here's how it's done just to refresh the memory:

<input 
  on:change={handleChange}
  ...
>

And as always, you'll receive the event object via params.

One thing we can do is to declare the event handlers inline using arrow functions like so:

<div on:mousemove="{e => m = { x: e.clientX, y: e.clientY }}">
    The mouse position is {m.x} x {m.y}
</div>

Much has been talked about using arrow functions in React's JSX and how using them can affect performance due to the functions being destroyed and recreated on each re-render.

However, this is not an issue in Svelte. I'm guessing that due to its compilation process, the framework will just create and bind the function once. So we can be sure our performance won't be affected by this practice.

Modifiers

Svelte introduces something called modifiers, which help us alter the behavior of our event handlers when we declare them. The syntax will be something like on:event|modifier={eventHandler}. The modifiers can be chained as well, like so: on:event|modifier|modifier={eventHandler}.

These modifiers will run between the triggering of the event and your handler. So far you can use the following modifiers -I'm just pasting the list from Svelte's tutorial cause there's nothing more to add-:

preventDefault: calls event.preventDefault() before running the handler. Useful for client-side form handling, for example.

stopPropagation: calls event.stopPropagation(), preventing the event from reaching the next element.

once: remove the handler after the first time it runs.

self: only trigger handler if event.target is the element itself

passive — improves scrolling performance on touch/wheel events (Svelte will add it automatically where it's safe to do so)

capture — fires the handler during the capture phase instead of the bubbling phase (MDN docs)

So far we don't have these in React and even tho they are useful I don't see them strictly necessary as you can achieve the same or similar results programmatically when you need to. Still, a very cool feature that will certainly save us some extra lines of code.

Component Events

It is most likely that you'll want to dispatch events from your components. You can achieve this by creating an event dispatcher in the component you want to trigger the event from. You can then handle that event on a parent component.

In the example below, we are passing the function sayHello to a button element, it will handle the click event on that button. Then, by using the dispatcher we will send another event to the parent component:

<script>
    import { createEventDispatcher } from 'svelte';

    const dispatch = createEventDispatcher();

    function sayHello() {
        dispatch('message', {
            text: 'Hello!'
        });
    }
</script>

<button on:click={sayHello}>
    Click to say hello
</button>

The parent component will then receive the dispatched event in the handler you passed to the Inner component.

<script>
    import Inner from './Inner.svelte';

    function handleMessage(event) {
        alert(event.detail.text);
    }
</script>

<Inner on:message={handleMessage}/>

I don't think it can get simpler than this. Now, I did a small experiment following the approach I am used doing in React and it worked just the same. Here I am using a different name for the on:message attribute. I am instead passing a prop called onClick and using it inside the Inner component. Now, remember that if we want to use a prop inside a child component we have to do export let onClick at the top of our script section.

<script>
    export let onClick;

    function sayHello() {
        onClick('Hello!')
    }
</script>

<button on:click={sayHello}>
    Click to say hello
</button>

And the parent:

<script>
    import Inner from './Inner.svelte';

    function handleMessage(message) {
        alert(message);
    }
</script>

<Inner onClick={handleMessage}/>

I wonder why this approach is not in the official tutorial, maybe because of this section talking about events and not about functions as props. You could still be in the need of using a function from a parent component inside a child component, for what you would probably use this approach.

Event Forwarding

If you've worked with DOM events you may know that these events bubble, meaning that the event is first handled by the element's handler and then it goes up the tree automatically, to each of its ancestors. This doesn't happen with Component Events unless you explicitly forward them.

Let's say you have three levels of components. We'll call them Top , Middle and Bottom. If you dispatch an event from the Bottom component and want to handle it in the Top component, this means the Middle component will need to forward that event. Svelte provides us with a very simple way to do it. We just need to declare an empty on:event in our Middle component. For example:

Bottom:

<script>
    import { createEventDispatcher } from 'svelte';

    const dispatch = createEventDispatcher();

    function sayHello() {
        dispatch('message', {
            text: 'Hello!'
        });
    }
</script>

<button on:click={sayHello}>
    Click to say hello
</button>

Middle:

<script>
    import Bottom from './Bottom.svelte';
</script>

<!-- Empty on:message will forward the event to the Top component -->
<Bottom on:message/>

Top:

<script>
    import Middle from './Middle.svelte';

    function handleMessage(event) {
        alert(event.detail.text);
    }
</script>

<Middle on:message={handleMessage}/>

You can also forward events on DOM elements in case you want to handle the event in a parent component instead of the one where the DOM element lives. Let's say you have a CustomButton component but instead of handling the click event in there you forward it to the Parent. You would do something like this:

CustomButton:

<style>
    /* Some custom styles here */
</style>
<!-- Empty on:message will forward the event to the Parent component -->
<button on:click>
    Click me
</button>

Parent:

<script>
    import CustomButton from './CustomButton.svelte';

    function handleClick() {
        alert('clicked');
    }
</script>

<CustomButton on:click={handleClick}/>

Pretty simple right? I really like the way how the empty on:event will forward the event to the parent component without any extra code. React to me feels the other way around. You would probably pass a handler function as props to the children and let them execute it wherever and whenever necessary. Of course, passing a function as props several levels down can get ugly but this shouldn't happen when taking care of the architecture.

Personally, I would try to avoid forwarding events more than two levels up cause I can imagine myself tracking down the component tree trying to find which component initially dispatched the event. I guess I'll get a better view of this once I start working on an app.

This is all for the third part, there's still a lot of topics to cover but I'll work on those during the following weeks. Thanks for reading and stay tuned!

Follow me on twitter: @jdelvx

Svelte from a React developer's perspective part 2: Reactivity & Props

José Del Valle — Mon, 17 Feb 2020 00:00:00 +0000

In the previous article I introduced myself into Svelte and explained some of the basics from a React developer's perspective. Today, I'm getting into it more in-depth and will explore how to derive values from state and how to pass props to child components while comparing Svelte's approach with React's.

Computed Values

Svelte calls these Reactive Declarations. With some special syntax, you can declare variables whose values will be derived from other variables. Let's say you have variable b whose value is derived from what variable a contains. Each time the value of a changes, the value of b will be recomputed.

The way of writing Reactive Declarations is by using a $: before the variable's declaration.In the following example, we compute or derive the variable age from the variable birthyear and each time we change the value of birthyear via the input element, the value of age will also be updated.

<script>
    let birthyear = 1993;
    let currentYear = new Date().getFullYear();
    $: age = currentYear - birthyear;

    function handleChange(e) {
        birthyear = e.target.value;
    }
</script>

<input 
    type="number" 
    id="birthyear" 
    name="birthyear" 
    min="1960" max="2020" 
    value={birthyear} 
    on:change={handleChange}
>

<p>Your age is {age}</p>

Reactive Declarations are useful when you want to reuse them in several places, so you don't have to do the computations over and over again.

Reactive Statements

Following the previous approach, you can also use Reactive Statements and put the $: before things like if or console.log statements. This can be useful if you only want to execute stuff if your variable in the state meets certain criteria.

Anywhere inside your script block you can do things like:

<script>
// Single statment
$: console.log(`Logging the value of ${age}`);

// Grouped statements
$: {
    alert(`Your year of birth is: ${birthyear}`);
    console.log(`Your age is: ${age}`);
}

// Conditional
$: if (age <= 20) {
    console.log('Hey you are still young!')
}

// Conditional Re-Setting Value
$: if (age < 18) {
    alert(`People less than 18 y/o are not allowed`);
    age = 18;
} 
</script>

Coming from React you may think all this may be unnecessary, given the fact that when working with React, if you want to have computed or derived values you just assign a computation to a variable. Depending on where you declare this computation it will run each time the state or the props change, or you can have it in a function that you can call whenever you want. All this without additional syntax.

Still, Svelte keeps this pretty simple and easy to remember so this shouldn't be a big obstacle.

Updating Arrays and Objects

React's rule of thumb is that you do not mutate the state directly. You have to make use of React's setState or hooks. By using them you make sure your state updates accordingly and your components react and re-render.

Svelte works the same way behind the scenes, although you don't have any setState or hooks.If you have an array and you push a value to it, there won't be any state update, unless you make a reassignment of that array with the updated value.

I see this re-assignment as our setState from React because it is this re-assignment that triggers the reactivity in Svelte.

As mentioned in the Svelte tutorial:

Svelte's reactivity is triggered by assignments.

I took the example from the tutorial and commented it to make this easier to understand:

<script>
    let numbers = [1, 2, 3, 4];

    function addNumber() {
        // We push a new value to the array
        // this won't trigger any state update
        numbers.push(numbers.length + 1);
        // We re-assign the updated array to the same variable
        // I see this as our setState or hook setter from React
        // Without this, there're no state updates
        numbers = numbers;

        // Instead of all this you can also do just
        // numbers = [...numbers, numbers.length + 1];
    }
</script>

<p>{numbers.join(' + ')}</p>

<button on:click={addNumber}>
    Add a number
</button>

When working with objects it gets kind of tricky because you have to understand how references work in Javascript. When assigning an object to a variable, this variable doesn't get a new copy of that object, instead, it gets a reference to the original object. This means that if you mutate a property on the newly declared one, it will also mutate the property from the original object.

Having said that, still after the mutation Svelte won't know that the state has to be updated, unless you make an assignment.

Again, a commented example would make this easier to understand:

<script>
    let obj = {
        foo: {
            bar: 'bar'
        }
    }

    function updateProperty() {
        // foo has a reference to obj.foo
        const foo = obj.foo;
        // Mutating foo.bar also mutates obj.foo.bar
        foo.bar = 'baz';
        // But you need a re-assignment of 'obj'
        // So Svelte updates the state accordingly
        obj = obj;
    }
    </script>

<p>
    {obj.foo.bar}
</p>

<button on:click={updateProperty}>
    Update Property
</button>

Now, the following also worked for me, by directly assigning the new value to obj.foo.bar.

function updateProperty() {
    obj.foo.bar = 'baz';
}

Props

We're finally talking about properties or just props. Just like React, we can pass properties down to our child components and the concept is the same. Svelte does it in a slightly different way tho.

In the next example, we are going to import a Child component and we're gonna pass a property called age to it. So far this is very similar to React.

<script>
    import Child from './Child.svelte';
</script>

<Child age={10}/>

Now, there's a difference in how this looks on the Child component. In React, you receive the props via the parameters in a functional component or via this.props in a class component and that's pretty much it.

In Svelte tho, this is how it would look on the Child component:

<script>
    export let age;
</script>

<p>My age is {age}</p>

At first glance, this doesn't make sense. Why would we want to use export when we want to use a property we are receiving from our parent component? Well, although it doesn't make sense from a semantical standpoint my interpretation is that we are exposing the property to the rest of our component so we can use it in our elements below.

Default Props

We can specify default values for the props in the Child component just like this:

<script>
    export let age = 0;
</script>

This way, if the component doesn't receive the property we can show a value instead of undefined. This is the same as React's defaultProps but with a little bit of less code.

Spread Props

And last but not least, we can use our friend the spread operator when we want to pass several properties to our children.

So instead of doing this:

<User name={userInfo.name} age={userInfo.age} email={userInfo.email}/>

We can do the following:

<script>
    import User from './User.svelte';

    const userInfo = {
        name: 'José',
        age: 27
        email: 'jose@email.com'
    };
</script>

<User {...userInfo}/>

This is all for the second part, there's still a lot of topics to cover but I'll work on those during the following weeks. Thanks for reading and stay tuned!

Follow me on twitter: @jdelvx

Svelte from a React developer's perspective: The Basics

José Del Valle — Fri, 07 Feb 2020 00:00:00 +0000

So I don’t know a thing about Svelte. I mean, yes. I know it’s a new framework for building web apps and that it’s generating a lot of buzz but that’s pretty much it. Instead of reading articles by other fellow developers I’ve decided to introduce myself into the thing and give it a go from a React developer’s perspective.

I’ve been a React developer for about 5 years now so I’m pretty excited about learning a new and - I hope - refreshing technology.

So, I went to the Svelte site and started doing their tutorial. Here are my thoughts as I go through it. What I want to do is to write about the similarities and differences I find between Svelte and React that I consider worth mentioning.

Compilation vs Interpretation

Right on the first page of the tutorial you can read the definition of what Svelte is and the main reason it is different than other frameworks:

Svelte converts your app into ideal JavaScript at build time, rather than interpreting your application code at runtime.

When you compile a Svelte app, you end up with plain Javascript code and the browser doesn't have to run nor download anything specific to Svelte to do any of the UI operations. With React, on the other hand, the browser needs to download the React library to do all the stuff we are used to, more specifically the Virtual DOM diffing.

Not having to download any code to do UI operations means your apps are smaller and load faster on the browser.

I still wonder how much of a benefit there is when introducing third-party libraries but I'll leave that for future posts.

No Virtual DOM

Unlike React, Svelte doesn't do Virtual DOM diffing to update the DOM. When you compile Svelte apps, you end up with the Javascript code that is responsible for updating the DOM when the state of your app changes. This way your apps are not subject to any overhead related to Virtual DOM operations.

Markup

So, at a glance, it seems that Svelte’s markup shares some similarities with React’s JSX. I’ve also spotted some cool differences. Let’s take a look:

Svelte also uses curly brackets to pass data to elements.

The code below is actually valid Svelte and JSX from a syntactical standpoint:

<h1>Hello {name}!</h1>

Of course, we’re not yet looking at the surrounding Javascript where the variable name lives but so far we are presented with a similar approach for dealing with this.

Svelte has a very cool ‘attribute shorthand’ feature

This does not exist in React and I love it. See the code below:

<img src={src} alt="A man dances.">

With Svelte, we can just do the following

<img {src} alt="A man dances.">

We’ve dropped the src={src} in preference of just {src}. Very cool!

Working with Svelte files feels more like working with HTML

So, to develop Svelte components you have to write your code in .svelte files, which just feel like modular HTML with Javascript and CSS specific to the component you are working on.

My current approach with React files is to have the component-specific styles in the same file using styled-components so this feels similar to me. It just looks a little bit more sectioned.

Here's a quick example of a very simple .svelte file:

<style>
    p {
        color: blue;
    }
</style>

<script>
    let name = 'José'
</script>

<p>Hello {name}!</p>

Importing and using external components looks like React

So, putting the Svelte structure aside, importing and using external components feels the same.

Here's a small example of that:

<script>
    import Nested from './Nested.svelte';
</script>

<p>This is a paragraph.</p>
<Nested/>

Svelte has a dangerouslySetInnerHTML but without the spooky name

So, everyone has used React's dangerouslySetInnerHTML at some point. Svelte has exactly the same without putting the word dangerous in it. You just have to use a @html prefix before the variable that contains the HTML string.

Still, this is dangerous. Both React and Svelte advice that injecting HTML could be a vulnerability for cross-site scripting (XSS).

<script>
    let string = `this string contains some <strong>HTML!!!</strong>`;
</script>

<p>{@html string}</p>

Reactivity

Finally, the part where we take a look at DOM updates given state changes.Here things look a bit different from React but it's still Javascript and it's kinda cool!

Let's take a look at the following code snippet:

<script>
    let count = 0;

    function handleClick() {
        count += 1;
    }
</script>

<button on:click={handleClick}>
    Clicked {count} {count === 1 ? 'time' : 'times'}
</button>

Unlike React where we declare a state object in a class component or use Hooks in functional components, we just declare the variable we want to change and the event handler function that will update that variable. So far that sounds like plain Javascript. The key here is in the button element and the syntax on the event handler attribute.

Instead of using onClick we use Svelte's on:click. This will tell Svelte to generate the necessary code that will update the DOM when the value of the variable count changes. Remember, all the browser will get is plain Javascript and no DOM diffing is involved here. Just like they mention on their homepage:

Svelte generates code that surgically updates the DOM.

This is all for now but there's still a lot to cover. I'll work on a second part during the following days and hopefully create some app in the following weeks.

Thanks for reading!

Follow me on twitter: @jdelvx

Serving a Gatsby site from DigitalOcean using Nginx

José Del Valle — Fri, 03 Jan 2020 00:00:00 +0000

It is well known that sites made with Gatsby can be deployed to Netlify. This blog is hosted on Netlify for free! But you could as well be in the need to deploy a Gatsby site to another service like DigitalOcean.

I have been working on a Node + React application for some months now and it is hosted on DigitalOcean. A couple of weeks ago I stumbled upon a new requirement. I had to deploy a Gatsby blog to that same server and access it through the same domain.

The process was very straightforward but I had to do some tweaks to both my Gatsby and Nginx configurations. I’ll describe it here step by step. It shouldn’t take you more than an hour to set everything up.

Before moving on:

I assume you already have a DigitalOcean account and an Ubuntu Droplet created. The commands used in this guide may also work on other Linux Droplets but I worked with an Ubuntu one.
Make sure you have Nginx installed on your Droplet as we are gonna use it to serve our Gatsby generated static files.
You have your Gatsby project hosted on a remote repository like Github. For this guide, I’m just gonna clone a Gatsby starter from the starters library. You’ll need Git installed on your Droplet to clone your repo.
Optional: Install Node and Npm on your Droplet. I chose to perform the build on my Droplet so I needed NPM installed for both installing all the dependencies and performing the build but you can also just build your Gatsby site locally, push the built files to your repo and pull them from your Droplet.

SSH into your Droplet

So to perform all the cloning, building and setup we’ll need to remotely connect to our Droplet via SSH. Here’s the guide for doing so if you’ve never done it.

Clone your Gatsby project

Once in your Droplet, clone your Gatsby project from your remote repo. I did this at the root to keep it simple. For this guide, I’m just gonna clone a gatsby starter I liked by Justin Formentin

git clone https://github.com/justinformentin/gatsby-v2-tutorial-starter.git

Install dependencies and build project

You can ignore this step if you already had your built files pushed to your repo. This way you can avoid installing the dependencies and building on your Droplet. I preferred to perform all this on my Droplet.

On the terminal, go into your project folder

cd gatsby-v2-tutorial-starter

Let’s first install gatsby-cli globally:

npm i -g gatsby-cli

Then install all the project dependencies:

npm install

Now perform the build with either:

gatsby build

npm run build

If everything went well, a /public folder should’ve been created. It includes the static files that we’re gonna serve through Nginx.

Configure Nginx to serve your Gatsby static files

Before configuring Nginx, we have to create a symbolic link from where your Gatsby static files are to where Nginx expects to serve these files.

Nginx serves files that are in the var/www folder but instead of moving our files over there we just create a symlink:

sudo ln -s /home/jose/blog/public /var/www/blog/html

Remember to put the path where your Gatsby files are as the first parameter. As for the second parameter, make sure you created a directory in there, in my case I created a /blog directory and an /html directory inside it.

Now, to configure Nginx to serve those files we have to open the default Nginx config file and make some tweaks. Let’s first open the file using nano:

sudo nano /etc/nginx/sites-available/default

Paste the following config in there. Preferably after the server_name property.

location / {
    alias /var/www/blog/html/public;
    index index.html;
}

About the server_name ; the default value is an underscore, this means you’ll need to access your site using the server’s IP address. If you are using a domain, that’s where you should put it. For example:

server_name example.com www.example.com;

Save and exit nano and then restart nginx using the following command:

sudo systemctl restart nginx

And that’s it!

Test your site!

If everything was configured properly, you should be able to access your blog either through your domain (if you configured Nginx to use it) or through the server’s IP address.

Nginx bonus: Configure Nginx to serve two sites from the same domain

As I mentioned above, the reason I had to deploy a Gatsby site to Digital Ocean rather than Netlify was that I already had a Node + React app running in Digital Ocean and I had to deploy the blog to the same server and use the same domain for both apps.

I used the following Nginx configuration to accomplish this:

location / {
    proxy_pass http://localhost:4000;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection 'upgrade';
    proxy_set_header Host $host;
    proxy_cache_bypass $http_upgrade;
}

location /blog {
    alias /var/www/blog/html/public;
    index index.html;
}

What I have there is the Node + React app being served at the root and the blog being served at /blog.

Now, there's a small change we have to do to our Gatsby config. We have to add a path prefix so our blog's routing works with a /blog prefix before the rest of the path. This is a very simple change described here.

This way our articles' url will look like: example.com/blog/posts/post-slug.

And that’s it! I hope this was useful and if you have any comments or feedback feel free to reach out.

Cheers!

My tech stack for 2020

José Del Valle — Mon, 18 Nov 2019 00:00:00 +0000

We’re now at the end of the year 2019 and it is that time when everyone starts planning what to do next year. 2019 was a great year for me in terms of coding. My previous job was great and my once side-project - now full time - has allowed me to work with very cool tech. While I’m mostly gonna keep using the same stack on my main project I’ve also decided my path for next year in terms of learning new things.

In this post, I’m gonna talk about my main project’s stack and what I’d like to learn in 2020.

React

I’ve been working with React since 2015 and I feel very comfortable with it now. I’ve worked on projects of all sizes and it has never let me down. There are very cool features coming to React like Suspense and Concurrent Mode - both experimental at the moment - that are worth checking out. React is alive and their team hasn’t stopped shipping new features each year so I still feel it’s gonna keep leading the front-end development world.

Special mention to Gatsby. My blog is made with Gatsby, a React framework that helps us developers build really fast static sites. Before launching my blog I was using Jekyll which was great but sincerely, being a JS and React developer, Gatsby felt so much better so I migrated to it and I don’t regret it at all. I’m sticking with Gatsby for 2020.

Styled-Components

I’ve been using CSS and Sass for styling my web applications for a long time now but a couple of months ago I tried a new approach. It’s called CSS-in-JS and several libraries follow this approach: JSS, Emotion, Glamorous and Styled Components just to a few. Even the Material-UI library has its CSS-in-JS solution.

The basic idea is that you write your styles in your Javascript, some libraries will let you use CSS syntax which I prefer. Some will inject the styles in your HTML whereas some will create classes and append these to your HTML elements.

As for myself, after using JSS, Emotion, MUI and Styled Components I decided to choose the latter on my main project, mostly due to the developer experience it gave me. It just felt pretty straightforward to use with React and I just love how clean the JSX looks when using it. The other ones I tried were great too actually, they are easy to work with and provide a lot of flexibility so switching between them shouldn’t be a problem for anyone.

GraphQL / Apollo

When I started working on my current personal project I decided to work with a completely new approach for the web API. I first heard about GraphQL a couple of years ago but wasn’t until January 2019 that I started working with it using the Apollo libraries on both the server-side and client-side and it’s been pretty challenging and fun.

It presents a different approach than REST APIs, letting you choose which set of data to receive from the back end, using one single endpoint. Do you want all the fields from a record or just a couple? No problem, you just have to declare which fields you want to fetch.

Using react-apollo makes fetching data from the API easy and clean on the front-end and apollo-link-state lets you manage your local state using the GraphQL way. I found apollo-link-state to be a good alternative to Redux which I used heavily in the past but have grown tired of.

Going to the back end, integrating Apollo Server with Express and Mongoose on the back-end has been a breeze. You can also mix GraphQL with REST in case you cannot migrate everything or if you still need to call some third party REST APIs.

All in all, I’m using Apollo not only as an intermediary between client-side and server-side but also to manage the client-side's local state.

NodeJs / Express

NodeJS has been my goto backend framework when developing web apps. I mostly worked on front-end development while on my previous jobs, but when I decided to work on my project I knew I had to choose something I felt comfortable with for the back-end and being mainly a Javascript programmer, NodeJS was the obvious choice. As mentioned above, integrating with Apollo was a breeze and when I also decided to use MongoDB as my database I didn’t find any big obstacle during the early stage development.

NodeJS is not new anymore but it has been widely adopted and today remains as one of the most powerful and versatile solutions for web applications so I’m still gonna use it in 2020.
MongoDB

I’ve used MongoDB since I was in college and while I stopped using it while on my previous jobs I kept studying and using it on my side-projects. For my current project, I needed good performance on geolocation data retrieval and I remembered MongoDB had a nice set of geolocation indexes that fit nicely for this requirement.

Several, NoSQL alternatives to MongoDB exist and may be better for some use cases but this time I also wanted to work with something I was familiar with to boost up development speed so I went with MongoDB once more.

What I’m learning in 2020

Vue

So as I mentioned above, I’ve worked with React for several years now. I’ve worked with Angular as well but not at the same degree. Still, I’ve chosen Vue as my new front end framework to learn in 2020. I don’t think I’m ditching React any time soon but I want to have a fresh alternative and Vue seems a good candidate. If I get the opportunity to start a new web app even for the sake of learning I’m gonna go with Vue and just enjoy the ride.

Python, Computer Vision, and Machine Learning

Python is on fire at the moment and is one of the big programming languages when it comes to Data Science and Machine Learning, the latter being a topic I’m interested to dig more into. A couple of weeks ago I decided to introduce myself to Computer Vision and I’m enjoying it a lot. So far I’ve used OpenCV and PyTorch for some object detection tasks. The reason I’m getting into this field of computer science besides my interest in learning is that I got a project idea where Computer Vision is indispensable so I’ll dedicate a big chunk of my time to it during 2020.

Besides that, anything that involves Machine Learning will be used more and more as time goes by and getting into this field seems like a safe bet.

Blockchain

Blockchain technology is another topic that I’m very interested to dig into and it’s also something that has been growing lately due to its potential. The main purpose of using blockchain technology is to create decentralized, transparent and secure systems. Its most common use case is cryptocurrency but there are a lot of possibilities that can be addressed with it and each year it’s getting more and more buzz. 2020 will be my introductory year into the Blockchain.

So, that’s my stack for 2020. Feel free to comment, suggest and give any feedback you like. Do you know of cool resources for learning more about any of these topics? Just let me know!

Thanks for reading!