DEV Community: Soo Yang, Tan

Simple way for managing your props in React

Soo Yang, Tan — Sat, 26 Oct 2019 15:23:45 +0000

If you have been developing an application that uses React, you might run into a situation where it becomes difficult or messy to manage the component props. A common scenario would be passing global data such as authenticated user details to deeply nested components.

Below is a simple example to demonstrate the passing of props from a top level component containing the userDetails all the way to the child component that renders the details on a user profile page.

We have an App component with the authenticated user details (global data). For simplicity, we will define the userDetails as a constant. We will have a component that look something similar to the following:

App.js

const App = () => {  
  const userDetails = {
    name: "User1", 
    address: "NY", 
    status: "active", 
    dateJoined: "January 2019"
  }
  return (
    <Profile userDetails={userDetails}/>
  );
}

The App component will render the Profile component which will be the user profile page. In order for the userDetails to be available on our profile screen, we pass it as a prop to the Profile component.

Our Profile component will like the following:

class Profile extends Component {
    render() {
        const { userDetails } = this.props
        return (
            <React.Fragment>
                <PrimaryDetailsCard userDetails={userDetails} />
                <SecondaryDetailsCard userDetails={userDetails} />
            </React.Fragment>
        )
    }
}

Profile component will render PrimaryDetailsCard and SecondaryDetailsCard component which carries diffrent kind of CSS styles for rendering different kinds of user details for the profile page. We once again have to pass userDetails as a prop to PrimaryDetailsCard and SecondaryDetailsCard component.

Example of PrimaryDetailsCard and SecondaryDetailsCard code:

PrimaryDetailsCard.js
class PrimaryDetailsCard extends Component {
    render() {
        const { userDetails } = this.props
        return (
            <div>{userDetails.name}, {userDetails.dateJoined}</div>
        )
    }
}

SecondaryDetailsCard.js
class SecondaryDetailsCard extends Component {
    render() {
        const { userDetails } = this.props
        return (
            <div>{userDetails.address}</div>
        )
    }
}

The passing of props makes it hard to manage and it will get even more complex.

React.Context to the rescue!

We can avoid the hassle of passing props to multiple nested components especially if they do not need to know the details. We can use React.Context for that!

We start by declaring a UserContext in a new file using the built in function const UserContext = React.createContext({});.

Inside our example App.js, simply import the UserContext and use UserContext.Provider to wrap all the components.
The provider simply allows the children component to receive the context value.

import UserContext from './UserContext';

const App = () => {
  const userDetails = {
    name: 'User1',
    address: 'NY',
    status: 'active',
    dateJoined: 'January 2019',
  };
  return (
    <UserContext.Provider value={userDetails}>
      <Profile />
    </UserContext.Provider>
  )
};

Now that we have UserContext.Provider set up with the userDetails set as its value, our Profile component does not need any knowledge regarding userDetails, we can simply remove the codes relating to the userDetails.

class Profile extends Component {
  render() {
    return (
      <React.Fragment>
        <PrimaryDetailsCard />
        <SecondaryDetailsCard />
      </React.Fragment>
    );
  }
}

The next part would be obtaining the context value inside our child component that are interested in the values. Using PrimaryDetailsCard as an example:

import UserContext from './UserContext';

class PrimaryDetailsCard extends Component {
  render() {
    return (
        <UserContext.Consumer>
            {(userDetails) => {
                return(
                    <div>
                    {userDetails.name}, {userDetails.dateJoined}
                  </div>
                )
            } }
        </UserContext.Consumer>

    );
  }
}

We import the UserContext and wrap our component with UserContext.Consumer component. The Consumer component will enable our component to access the value which was previously set by the Provider. With that, we have organized our props neatly while displaying our User details on the profile page as usual!

You can learn more about React.Context here
You can checkout my sample code on:
1) Without React.Context
2) Using React.Context

Uncovering tiny little magic in Rails

Soo Yang, Tan — Wed, 23 Oct 2019 07:42:14 +0000

Recently I got really curious with one of the magical things in Ruby on Rails framework. Let's take a look at the following code:

class User < ActiveRecord::Base
  validates_presence_of :name
end

As a Rails developer, we understand that validates_presence_of :name helps us to easily perform a modal validation to ensure that the name attribute must be present. BUT wait a minute.. where does this come from?

The beauty of Rails is that the framework provides a bunch of methods we could conveniently use out-of-the-box to perform difficult things easily. Back to our example, we can find this magical method validates_presence_of being defined inside the rails sourcecode. This magic is just another class method.

You may be curious on how did I manage to find the method in the source code. A good starting point to look at the rails sourcecode would be under activerecord since our model inherits from ActiveRecord::Base.

This is quite a common pattern in the Rails world. Some other examples would be has_many, acts-as-taggable, has_paper_trail and etc.

You can easily implement this pattern in your project. All you have to do is to define a class method in your parent class. You sub class will be able to use the method right away. Below is a simple code sample to demonstrate on how you can write it yourself.

class Employee
  def self.onboarding_pack(department)
    # Insert any complex logic here. For simplicity, this sample only prints a sentence. 
    puts "Onboarding pack for #{department} employees"
  end
end

class Developer < Employee
  onboarding_pack "Developer"
end

class Clerk < Employee
  onboarding_pack "General"
end

puts Developer.new # Onboarding pack for Developer employees
puts Clerk.new # Onboarding pack for General employees

Takeaway

Alot of convenient things (methods, generators and etc) provided by Rails will seem like magic on the surface. If we stay curious and take a dive into the rails sourcecode, you will be able to uncover its magic.

Power of ActiveRecord and when to stop using it

Soo Yang, Tan — Thu, 31 Jan 2019 07:55:11 +0000

In Rails, ActiveRecord makes it super easy to query for data from the database--but how well does it perform for your use case?

Scenario

Let's assume I have a Project model on my rails app. I would like to display the total number of project that are active and pending at a status against the total number of active projects on a dashboard.

Which would look something like this:

  Team Lead Action (25/100) | Manager Action (32/100)

Implementation

Thanks to ActiveRecord, we can easily achieve get the total count:

  active_projects = Project.where(status: 'active')
  @total_number_of_active_projects = active_projects.size
  @projects_pending_team_lead_approval = active_projects.reject(&:team_lead_action_time).count
  @projects_pending_manager_approval = active_projects.reject(&:manager_action_time).count

Voila! We can easily call these variables to display them on the dashboard. Problem solved!

However, I'm a little concerned if the amount of projects scales to a large amount. For example, just try imagining if we now need to display 5 different values, our queries will scale like this:

active_projects = Project.where(status: 'active')
  @total_number_of_active_projects = active_projects.size
  @projects_pending_team_lead_approval = active_projects.reject(&:team_lead_action_time).count
  @projects_pending_manager_approval = active_projects.reject(&:manager_action_time).count
  @projects_pending_manager_2_approval = active_projects.reject(&:manager_2_action_time).count
  @projects_pending_manager_3_approval = active_projects.reject(&:manager_3_action_time).count
  @projects_pending_manager_4_approval = active_projects.reject(&:manager_4_action_time).count
  @projects_pending_manager_5_approval = active_projects.reject(&:manager_5_action_time).count

That don't look very scalable. For such simple data value, it should be retrieved efficiently.

Let's verify things using data with the help of Benchmark with N = 1000:


                        user     system      total        real
count_active_project  0.066184   0.108178   0.174362 (  0.182557)

It takes about 0.18s. This time let's just change the query:

  active_projects = Project.where(status: 'active')
  @total_number_of_active_projects = active_projects.size
  @projects_pending_team_lead_approval = active_projects.where(team_lead_action_time: nil).size
  @projects_pending_manager_approval = active_projects.where(manager_action_time: nil).size

And benchmark it:


                              user     system      total        real
count_active_projects_ar    0.001460   0.000166   0.001626 (  0.002965)

This query which does the same thing takes only 0.002s - significantly faster. The difference is this time we are not using .reject - ( array method ) but instead relying on ActiveRecord. But why? Let's take a look at the logs.

Using .reject:

irb(main):036:0> Project.where(status: 'active').reject(&:team_lead_action_time).count
  Project Load (2.2ms)  SELECT "projects".* FROM "projects" WHERE "projects"."status" = $1  [["status", 0]]

Using ActiveRecord:

irb(main):040:0> Project.where(status: 'active', team_lead_action_time: nil).size
   (0.9ms)  SELECT COUNT(*) FROM "projects" WHERE "projects"."status" = $1 AND "projects"."team_lead_action_time" IS NULL  [["status", 0]]

As we can see from the output, .reject load the projects into the memory before processing while ActiveRecord will let the database handle the query. Database is fast and was designed to handle such process hence the speed improvement.

Annnd there's raw SQL

Taking a step further, we can write raw SQL in rails.

  query = <<~SQL
    SELECT
      SUM(CASE WHEN status = 0 THEN 1 ELSE 0 END),
      SUM(CASE WHEN status = 0 AND team_lead_action_time IS null THEN 1 ELSE 0 END),
      SUM(CASE WHEN status = 0 AND manager_action_time IS null THEN 1 ELSE 0 END)
    FROM
      PROJECTS
  SQL

  ActiveRecord::Base.connection.execute(query)

And the result is:


                              user     system      total        real
count_active_projects_sql    0.000250   0.000047   0.000297 (  0.000966)

Raw SQL only takes 0.0009s which is about 20 times faster.

Taking a look at the log:

irb(main):044:0> Project.count_active_projects_sql
   (0.8ms)  SELECT
  SUM(CASE WHEN status = 0 AND team_lead_action_time IS null THEN 1 ELSE 0 END)
FROM
  PROJECTS
=> #<PG::Result:0x00007fa3cdc1c460 status=PGRES_TUPLES_OK ntuples=1 nfields=1 cmd_tuples=1>

Raw SQL is significantly faster because it does not need to instantiate a new ActiveRecord objects which is slow but instead it returns a PG::Result object.

If we increase N = 100000, the benchmark result will be:

                              user     system      total        real
count_active_projects      4.428081   7.626659  12.054740 ( 12.177786)
count_active_projects_ar   0.002107   0.000303   0.002410 (  0.062542)
count_active_projects_sql  0.000380   0.000057   0.000437 (  0.026585)

We can clearly see that using raw SQL is the fastest 🏆.

Takeaway

1) In the end, I decided to go with the raw SQL method. Putting performance in mind, raw SQL is suited in handling such scenario.
2) Between raw SQL and ActiveRecord, in most cases ActiveRecord would be preferable for developers productivity.
3) Be careful with the methods used. Ruby .reject - (array methods) are great but use them with caution.

Depending on the scenario, solutions may vary. We can write our code creatively and test it out to fit our needs. We need to stay curious and be creative in improving our solutions.

** The example code can be found here https://github.com/sooyang/query_speed_example