DEV Community: Rishi Kumar Chawda

React Native just got better! The New Javascript Engine is here!

Rishi Kumar Chawda — Thu, 11 Jul 2019 18:14:10 +0000

Hermes Engine for React Native is here!

So it started from here :

// Detect dark theme var iframe = document.getElementById('tweet-1149347916877901824-947'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1149347916877901824&theme=dark" }

Facebook officially released React Native v0.60.2 about two hours ago which enables the engine as an opt-in feature. This brings a really big advancement on mobile development with React Native as it will give the Android Applications built with react native a significant boost in performance, smaller build size and less memory usage! 💜❤️

// Detect dark theme var iframe = document.getElementById('tweet-1149354596558671872-535'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1149354596558671872&theme=dark" }

And the integration is so easy! Just enable it in your build.gradle file and that's it. Done 🙆‍♂️ Literally, JUST ONE LINE OF CODE AND THATS IT! ✨

You can see the difference on app startup here!👇 :

// Detect dark theme var iframe = document.getElementById('tweet-1149365887427727361-989'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1149365887427727361&theme=dark" }

The only thing is that you need to upgrade React Native to version 0.60.2 which has a lot of significant changes (RN v0.60 was released a week ago - see changelog here) but well, the improvement for Android apps with this engine is AWESOME! Definitely trying it over the weekend! 💪

Oh, and don't forget to follow this discussion on Hermes' official twitter account!

// Detect dark theme var iframe = document.getElementById('tweet-1149370023539961856-945'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1149370023539961856&theme=dark" }

Who all are excited for this? I definitely am!

You can also follow me on twitter for my shitposts and retweets! 🤓

What's your plan for the weekend?

Rishi Kumar Chawda — Thu, 11 Jul 2019 12:22:42 +0000

Weekend is near and again it's time to focus completely on some personal endeavours! 📸🏃‍♂️

Although a lot of people feel / think that we should relax or do something else, including my family and friends, I rarely find myself interested in anything other than sitting with my laptop. 👨‍💻

Whatever helps you relax, you should do it. And I utilise that time to learn new things or strengthen my expertise.

This weekend, I am going to work on improving my skills on Progressive Web Apps and service workers. 💪 And planning to try out one or two from the tools I found on React Native development (I have a few on my browser's history that would serve as a checklist). Might also finish writing another article too! 🤓

What are your plans?

Architecting React Applications - What I learned from my experience as a Web developer

Rishi Kumar Chawda — Tue, 02 Jul 2019 16:40:06 +0000

React has always been popular for its short learning curve and easy to use APIs. But if you have been working with this popular javascript library for a while now, you might agree with me on this one as well -- If you don't pay attention to it's structure it will soon become an unmaintainable mess.

Before joining my first job, I had some experience as a freelancer but didn't know much about best practices and architecture apart from what I had come across either online or while development. And even as a freelancer I didn't have experience with such large scale applications that we had to work with later in the job. This is when I started paying more attention to architecture. In the start, things used to get a little confusing sometimes - mostly because I was a bit more conscious about my code than before - which was obvious as I was part of a team now and not a solo freelancer.

So I started looking through GitHub, online articles, papers and books. And as I kept working with React more and more on a large scale I had realised that

The key to a robust, scalable and easy to maintain React application is architecture.

This applies to any application or software but with React, abstraction was a bit more difficult than other libraries / frameworks. This was until Hooks were introduced - but we will keep it out of the context for now as it is still fairly new and most of the applications are still built with older versions of React. Also, there are a lot of improvements to be made; lot of do's and dont's to be discovered with its usage.

As of now, I think the principle that I follow for structuring React applications will work fairly well with Hooks too! Since the focus was on a scalable web application architecture - not just React.

Let's quickly take a look at the setup and then I'll walk you through it and try to explain why it is structured that way. So the root of the project looks something like this :

And the src directory ( which will contain all the source code for our application, ofcourse ) is structured like this :

The first thing you might notice, and wonder maybe - and if you don't, I'd recommend taking a look again - that we have two directories named config in our project. No, this isn't by mistake! It has a ( extremely ) simple reason.

Two config directories for a single web application?! Why though??

The config directory at the root contains all the configuration files related to build - like our application's webpack config or any other bundler that we might use, environment files and other configs.

You might also notice that it is nested and that the webpack configuration lives in its own directory. This makes the configurations more organised and easier to manage. This might seem trivial but when the application starts growing , and with that the build process might also get complex - which then demands a well organised place of its own. Also, this brings a peace of mind while working with it -- a large mess of configuration files is the last thing you might want while deploying your application in production! 👀

The other config directory inside our src folder is for configurations related to our application, .i.e, the ones related to runtime. This may contain our json files ( or any other files ) that might shape the behaviour or capabilities of our app. Although, this may or may not be required as per your needs but for me, I have had this folder in most of the projects.

But wait, what about the `resources` and `assets` directories? Aren't assets also a part of the 'resources' for our react application?

Well, the assets directory here is meant only for images and other media , duhh,

whereas, resources is for data that might be required by our web application, for example, constants and other static data which basically doesn't have any or much logic associated to it. You can also add small methods to return the data, perhaps formatted to specific needs, and / or perform minor operations on them there which can be used by parts of our application, which by the way -- trust me -- will make your code a lot cleaner and more organised.

This directory may also contain data and other 'resources' which can be occasionally fetched, stored and updated; and maybe processed a little before they are used in certain parts of our web application. Well, I guess - you get the idea.

And what about our pages and all the react components??

So, here comes the interesting part. Atleast I think so. This is something that has been derived from a few other solutions on architecting react applications as well as other web applications along with some of my own practical experience. And by far, I'm pretty satisfied with it! 🤓

To start with, let's assume our web application contains a home page, a profile page for the users and just for the sake of not having just two pages in the example, a third page that we will call -- the other page. So the directory structure would look something like this :

-- src
----- components
----- config
----- pages
--------- home
----------- index.js
----------- index.scss    // Mandatory sass file (wanted to make this look realistic!!)
--------- profile
----------- index.js
--------- other-page
----------- components
----------- index.js
----- resources

Notice how all the pages have their own separate directory with an entry point? And how that 'other' page has a component folder? Why do we need another component folder? Don't we already have a component folder in the root of src directory?

Wait, just hold on for a second! I'll explain it real quick! ☝️

This is what I call the "branching" structure. Each page has their own directory, their own set of components which are not used anywhere else except in that specific page, their own styles rules and other stuff which are associated with only that page. If any component is shared by two pages, guess where they'd go? Yes, you guessed it right -- the components directory in the root of our src directory!

But.. you might wonder.. what is the point of doing that?

Let's say, one day you and your teammates decide to get rid of the 'other' page -- maybe the name wasn't good enough? -- so what do you do? Spend an entire afternoon or a day on removing code, breaking and fixing the application? NO.

You just go ahead and delete the directory and remove its reference from where it was attached to / used in the web application. And voila, it's done! 💁🏻‍♂️

Nothing breaks in your app just because a bunch of code was deleted! Everything is independent of each other's existence even if they were binded together at some point! A lot less to work with and worry about, isn't it? And yeah, this principle can be applied to almost any application / software and not just some react application.

Some of you might think -- Well no, our application / software is quite complex and stuff is just too interconnected with each other. They shared code, were bridged together, etc. But I guess you might understand now what to do with the "shared code" and "bridges" if you try to apply this principle to it! This is just a simple example to demonstrate and give you an idea of how parts of the product can be organised for convenience and maintainability.

A little tip - something that I learnt while developing progressive web applications with GatsbyJS

You can also go ahead and add another directory to the src -- called layouts ( or maybe add it to the components directory, whichever feels more appropriate to you ) which contains a layout file which is global to the application, or even have multiple layouts ; each associated with certain parts of the application. For example, let's assume our application also has a fancy navbar and a decent footer which goes into all of our pages. Instead of having them shoved inside our components directory and then repeatedly used inside each page - we can have a layout file that contains the navbar and the footer and renders the children that are passed to it, like so :


<Layout>
  <div>
    Yayy! This is my fancy home page!!
  </div>
</Layout>

// And in the profile page :

<Layout>
  <div>
    This is the page of the user whose data we're secretly trying to steal! 
    Please read our privacy policies (not so) carefully!!
  </div>
</Layout>

And in our Layout file, we can have something similar to this :

const Layout = ({ children }) => (
  <>
    <Navbar />
    {children}
    <Footer />
  </>
);

export default Layout;

This makes your code more organised and logically abstracted. Also, it'll help in keeping your pages consistent.

But wait.. There's more to architecting react applications!!

Yes, I haven't forgotten about reducers, the lengthy sagas, services, a ton of action creators and what not! But that's for the second part of this article since I don't want it to become too long and exhausting to read. Also, this first part might serve as a good starting point for beginners or other developers who are new to React.

Thank you for reading! Let me know in the discussion thread below what you think about this post. 😄

You can also connect with me through Twitter.

Happy hacking! Cheers! 🎉

Automate lighthouse audits for your Progressive Web Application

Rishi Kumar Chawda — Tue, 02 Jul 2019 10:12:02 +0000

We all know how important and helpful the insights are from lighthouse audits when we're developing our web applications. But the way most of us check is manually through Chrome devtools or the lighthouse extension, which in my opinion, is not very productive.

For those of us who don't know, there are mainly four ways of auditing our web application with lighthouse :

Chrome devtools
Command line
NPM module ( which we are going to use in a while )
PageSpeed Insights

For the purpose of programmatically performing lighthouse audits, we will use the lighthouse npm package, mocha and chai for writing our tests and chrome-launcher for running our lighthouse tests.

First, let's install the above packages as dev dependencies in our project :

npm install lighthouse chrome-launcher chai mocha --save-dev

Now, let's create a file named lighthouse.tests.js in our tests directory. We'll run our lighthouse audits through this file.
Here, we'll import the lighthouse module and chrome launcher - which will enable us to open our webpage from local development server and run the audits to test against a minimum threshold that we want our lighthouse scores to be.

While this might sound a lot to do, it isn't much. Here's what it looks like on actual code :

const lighthouse = require("lighthouse");
const chromeLauncher = require("chrome-launcher");

function launchChromeAndRunLighthouse(url, opts, conf = null) {
  return chromeLauncher
    .launch({ chromeFlags: opts.chromeFlags })
    .then(chrome => {
      opts.port = chrome.port;
      return lighthouse(url, opts, conf).then(res =>
        chrome.kill().then(() => res.lhr)
      );
    });
}

And it is as simple as that. We launch the chrome browser instance with chromeLauncher.launch method and then run lighthouse tests with the site url and configuration for our audits. After that is done, we close / kill the chrome instance and return the results. This is how it looks like when in use :

launchChromeAndRunLighthouse(testUrl, opts, config).then(res => {
  // Results are available in `res`
});

So now, we can put this call inside our before hook for the tests and then have tests for each metric, something like this :

describe("Lighthouse Audits", function() {
  // Timeout doesn't need to be same. It can be more or less depending on your project.
  this.timeout(50000);
  let results;
  before("run test", done => {
    launchChromeAndRunLighthouse(testUrl, opts, config).then(res => {
      // Extract the results you need for your assertions.
      done();
    });
  });
  it("performance test", done => {
    // test your performance score against the threshold
    done();
  });
  // Some more tests..
});

Still looks weird? Don't worry! Checkout this repository for example setup of lighthouse tests with mocha and try that out with your web application!

(You can find a list of related projects through this link, including an example with jest)

This method can be applied to automate the tests in continuous integration / deployment environments so that you don't have to worry about manually auditing your web application and checking wether it meets the minimum satisfactory levels.

So there you go. That's all we need to do for automating lighthouse audits for our progressive web applications to make sure they are always worthy for the internet and user's data packets!

Thank you for reading! 😄

You can also connect with me via Twitter.

Happy hacking! Cheers! 🎉

Is Web Assembly the future?

Rishi Kumar Chawda — Tue, 02 Jul 2019 06:57:34 +0000

Recently, I have seen and read articles on web assembly out of curiosity and was wondering if it would be a significant part of web development in the future since it provides better performance than Javascript.

( I'm a Javascript developer - React and React Native - and was exploring more on web development so that I've something new to learn over the next couple of weekends. )

What are your thoughts, devs?

Managing React application state - without using Redux!

Rishi Kumar Chawda — Sun, 02 Jun 2019 04:45:34 +0000

Disclaimer: This solution is best suited for small scale projects and its main motive is to explore the new APIs react provides rather than trying to replace any traditional solutions.

So when was the last time you tried managing application state, without Redux? As far as I can remember, for me, it was probably during the time I had started learning and playing around with React. Although I had known about Redux at the time when I did try not using it, I just wanted to do it because I didn't want to add three dependencies to my react application just for managing a really small application state. Ofcourse, when we talk about using redux, we are also going to use react-redux and a middleware too!

I basically did it in two different ways ( which most of us, might have tried at some point as well ) :

Using localStorage and custom listeners.
Using the Context API.

But in this article, we're not going to discuss that. We're going to see another way of managing the state which is fairly new - using Hooks.

So, let's setup a react project and add a root component, like so :

And our ChildComponent.js as,

First, let us break down the complete flow and decide what we need :

A state, ofcourse
A way to mutate / update our state.
A way to sync the data from state to our components wherever required.
Do all of this while keeping the code clean. ( Very important )

Let's setup our state first. For this, I'm going to use the useReducer hook. For those who are not familiar with the useReducer hook - it is similar to the basic useState hook but more suited for this case as it provides a dispatch method, the previous state while computing and updating state, etc. Basically, it will provide us a way which is similar to Redux's reducer and action flow. Let's set up our useGlobalState hook which will help us initialize our state and provide us a dispatch for updating it as well.

So our redux.js looks like this :

So what's going on here? Our custom hook here takes two arguments - initialState for setting an initial state to our app and reducer is our reducer function which is going to be used for updating state depending on the actions.

Our reducer.js might look like this :

With those two arguments, we can initialise our reducer and state as :

const [ state, dispatch ] = React.useReducer(reducer, initialState);

Since our initialState might, in some cases, require some computation and may not be just a static value - we are going to use the third argument of useReducer to initialise our state from a function just incase we need to. So now we can initialise our state in two ways :

const globalState = useGlobalState(intialState, reducer);

 // OR

const globalState = useGlobalState(() => {
  // Do stuff here.
  return state;
}, reducer);

But, where do we initialise our state? Well, this needs to be done inside the root component since Hooks can only be called / used inside a functional component. Let's add this to our App.js file and use the classic example of making a simple counter.

This gives us something like this :

But still we can't use the state inside our ChildComponent since it has no idea of this state. So how are we going to do this?

This is a slightly interesting step now. We're going to use the createContext API for that. Let's update our redux.js to give us a way to pass the state to our child(ren) component(s), like so :

I guess you can clearly see where this is going. We are going to use the Provider component in our root App.js and wrap our component with it. Additionally, we'll pass an initial state as the value for our 'provider'. This makes the values available in the DOM tree. But then you might wonder - we need to wrap all our children who are going to use the state with context.Consumer, don't we? Well, no.

Here's where our React.useContext hook comes into play along with a little HOC trick. And we're going to name it connect so it looks similar to redux! Also, it will be easier to understand if we can visualise it in the 'redux way'. But first, let's check if our current setup works.

Update the App.js file to this :

And our ChildComponent.js like this :

So what does useContext hook do? Well, it's similar to using context.Consumer tag which allowed us to access context value and subscribe to its changes. With useContext hook, we no longer use the context.Consumer in our component. We pass the context object to it, which then returns the value from the current context. Whenever the context data changes, the component is re-rendered with the new values.

Let's see if this works.

Great! But there's one thing. Now we need to call useContext in every component! Let's get rid of this. We're going to write a small HOC which exposes an API similar to the connect HOC from react-redux.

Now, our redux.js should look like this :

Note : As you can see, we are just spreading the props over the component here. The ideal way is to use hoist-non-react-statics package to copy all non-react static methods to the new component. Please use that way since it is better than just passing the props. Complete explanation can be found in the React Documentation for Higher Order Components.

The connect HOC here takes our component and uses the context to get all the props that are required by the component as defined in the mapStateToProps function in the connect call. We can update our ChildComponent.js now, to something like this :

Let's check if this works.

Incase you're wondering, you can have different counters for both of them and it'll work just fine! You just need to initialise the state with both the counters, dispatch actions from their respective buttons and use the respective values from the state to display. Like so :

// In App.js, initialise counters like this
const globalState = useGlobalState({ count: 0, anothercount: 1 }, reducer);

/**
 * In ChildComponent.js, update the `mapState` and `mapDispatch` methods
 * to get and update `anothercount` value from state.
 */
const mapState = ({ anothercount }) => ({ // Get the `anothercount` value from state.
  count: anothercount,
});

const mapDispatch = (dispatch) => ({
  // Update the dispatch to trigger `countincrement` action.
  updateCounter: () => dispatch({ type: 'countincrement' })
});

export default connect(mapState, mapDispatch)(ChildComponent);

/** 
 * Finally, update our reducer to handle `countincrement` action,
 * which updates the `anothercount` value in our state.
 */
export default (state, action) => {

  switch (action.type) {
    case 'increment':
      return {
        ...state,
        count: state.count + 1,
      };
      case 'countincrement':
      return {
        ...state,
        anothercount: state.anothercount + 1,
      };
    default:
      return state;
  }
}

Oh, and one more thing! Don't forget to wrap your components with React.memo if they're not connected to state. This will prevent unnecessary re-renders when the state udpates!

And we're done implementing a small redux-like application state management in our react application! All within just 40 lines on code! ✨

You can check out the complete example in this github repository. Please leave a star on the repository or comment here if you liked this article!

You can connect with me via Twitter.

Thank you for reading! 😄

Happy hacking! Cheers! 🎉

Shrink your React Native application size dramatically!

Rishi Kumar Chawda — Sat, 01 Jun 2019 10:05:00 +0000

So you made a cool and awesome looking React Native app and now you’re ready to build it and maybe publish it to the store —

But worried about it if the users would want to install it given its build size? Or maybe you just want to keep it light weight and not take too much memory unnecessarily when it can be packed into a smaller size?

Or you’re just one of us who are paranoid about build sizes? Don’t worry, we got you covered! 😄 ✔️

In this article, we will cover the following two things:

Compress our react native application size - by compressing the java bytecode that is generated while building our app and also asking it to try and shrink all the resources that are bundled with the application.
Splitting our application bundle into multiple apks to remove unnecessary code which is not required by the device which is going to run it - because a lot of code is bundled with the universal apk that is device specific - meaning that we don't need a lot of code in the device we're going to install it in.

Let's get started! ✊

First of all, you’ll need to eject your native app if you’re using create-react-native-app for your project ( You might have already done this if you’ve built your application before reading this article ). This is important since you don’t have access to configurations until you eject, as the build folder is where we have to make changes. If you haven’t, you can simply do this by :

npm run eject

Note : Ejecting a react native application is a permanent action! ( Unless you’re using a version control system to keep track of previous versions of your app — from where you can recover the ‘unejected’ version of your app later if you need ). Learn more about ejecting.

Okay so now we’re all set! Let’s get started and get that done fast. Don’t worry it just takes a few minutes and your app size will shrink dramatically!

Now, navigate to the android / app folder from your project root directory where you can find your build.gradle file.

Here, you’ll find your default build configurations already setup, find the line which looks like this :

def enableProguardInReleaseBuilds = false
def enableSeparateBuildPerCPUArchitecture = false

and change their value to true like this :

def enableProguardInReleaseBuilds = true
def enableSeparateBuildPerCPUArchitecture = true

So you might be wondering what it does. Well, if you scroll down a bit you’ll see enableProguardInReleaseBuilds and enableSeparateBuildPerCPUArchitecture written at a few more places like here:

As you can see, these variables are being used to enable or disable two build configurations —

One for generating separate .apks for different device architectures,

...
splits {
    abi {
      reset()
      enable enableSeparateBuildPerCPUArchitecture
...

Don’t worry about having to handle different .apks for each architecture — Google takes care of distributing it to the users! And separating the builds according to architecture removes unnecessary code from your file which is not required on the device it is running.

Another one for compressing the Java bytecode generated while building, as in,

...
buildTypes {
    release {
        minifyEnabled enableProguardInReleaseBuilds
...

Phew, that was pretty easy! But wait, we’re not done yet! There’s one little thing we need to do.

Now let’s add this line right below the minifyEnabled configuration :

...
buildTypes {
    release {
        minifyEnabled enableProguardInReleaseBuilds
        shrinkResources true; /* <-- Add this line */
...

And we’re done! Now build your app again and check the output directory. You’ll find two different .apks of your app which are specified in the configuration by default, i.e., for armebi and x86 architectures.

Oh, and by the way if you need a universal .apk that supports all device architectures — just set universalApk to true and it’ll generate a universal .apk next time you run build!

That’s all! Now you’ve setup your build configuration to shrink your code along with resources and create separate .apk for different architectures — thus removing unnecessary code from the final build.

Thanks for reading! You can also check out more resources on how to reduce the application build size. 😄

Did you like this article? Or did I miss something? Is there something that you have that can be added to this article -- that can make it even better?

You can connect with me via Twitter.

Happy Hacking! Cheers!

DEV Community: Rishi Kumar Chawda

React Native just got better! The New Javascript Engine is here!

What's your plan for the weekend?

Architecting React Applications - What I learned from my experience as a Web developer

Two config directories for a single web application?! Why though??

But wait, what about the resources and assets directories? Aren't assets also a part of the 'resources' for our react application?

And what about our pages and all the react components??

A little tip - something that I learnt while developing progressive web applications with GatsbyJS

But wait.. There's more to architecting react applications!!

Automate lighthouse audits for your Progressive Web Application

Is Web Assembly the future?

Managing React application state - without using Redux!

Shrink your React Native application size dramatically!

But wait, what about the `resources` and `assets` directories? Aren't assets also a part of the 'resources' for our react application?