DEV Community: Jason M

Simplying State Management with Immer: Some Thoughts

Jason M — Sun, 31 May 2020 23:53:56 +0000

Not sure about the rest of you, but I find that with any mildly complex state in react / redux applications, updating state for objects deeper inside the state can be a pain.

Here's some state:

Suppose we want to make a change to the description for item 3 (id) in purchase 7 for account 1. Without a helper library, we'd do something like this:

All of this just to update a single field. The excess spreading makes the code hard to understand, and also introduces more opportunities to mess up and introduce bugs. Wouldn't it be better if we could just do something like this?

This code is a lot cleaner, more intelligible, and leaves less room for introducing bugs. Unfortunately, when we're working with state in react and redux, we need to avoid mutating state directly, so without a helping hand, we cant use the latter code snippet. Fortunately, Immer (a javascript immutability library), can provide us with that helping hand.

Rails: Using a custom serializer to serialize a collection of active record model instances

Jason M — Wed, 18 Mar 2020 02:39:31 +0000

So, serializers provide a standardized way to shape and characterize the data an endpoint needs to return based on a given response. There are a number of ruby gems that do serialization. One popular gem is 'active_model_serializers'.

If you have the active_model_serializers gem enabled in your rails app, and your endpoint renders some json, such as: 'render json: iAmAnActiveRecordBookInstance' -- well if you have a serializer in the serializers folder with the same name as the model instance, rails will make use of it, and provide the serialized data of your book, based on that serializer.

However, sometimes we may want to include or exclude information for a particular model instance based on relationships to other models. And, in this situation, it's likely we're going to have custom serializers that we wish to employ in the given endpoint. There is a simple way to do this:

render json: myModel, serializer: mySerializer

In this way we can utilize a custom serializer

However, often we have a list of active record associations we wish to serialize. If we just wish to let rails employ the default serializer action, then we can do something like this: render json: myModelInstance.all

In the above case, rails will look in the serializers folder for a serializer with the same name as the model instance, and apply it to all the items in the active record 'list'. This is fine if what you want are all your instances to serialize via the default serializer for the model. However, sometimes we don't want that: we want a custom serializer.

If you try this, you will run into an error: 'render json: Book.all, serializer: customBookSerializer'

So, why does this fail, just because we specify the serializer? A collection of instances is not an instance: A serializer for a collection of instances is not a serializer for an instance. When we left it to rails' default behavior, there is a check for whether this is just an instance of a model, or a collection of model instances, and rails would employ a collection serializer and the collection's instance serializer. But if we specify our serializer, we are taking control of the serialization process, and we need to be a little bit more specific if we want our custom serializer to apply to a collection of objects of a given kind.

So, here's how you make use of a custom serializer for a collection of active record model instances: render json: Book.all, serialize_each: customSerializer

Sometimes, your serializers may need information in order to serialize the information you need. You can pass in information, such as a userId or an itemId in this way:

'render json: Book.all, serialize_each: customSerializer, additionalProperty: additionalPropertyValue

Inside of your serializer, you can access additionalProperty as 'instance_options[:additionalProperty]'.

You might wonder, "why would I ever need to pass information to my serializer, if the relationships are set up correctly?" You might not need to. But one very useful case is where you have a many-to-many relationship with another model, via a join table, and you need to retrieve certain records from that join table, based on dynamic information. You can make a custom method in the serializer, and grab the relevant records via the dynamic information you pass in via instance options.

A Quick Intro to Using the FireBase key on a custom backend: Part One

Jason M — Tue, 25 Feb 2020 18:11:24 +0000

Firebase is an amazon suite of products aimed at supporting web and mobile applications. The services include various data storage options, as well as authentication services. Since authentication and authorization can be a pain, smaller teams / independent developers might very well want to ‘outsource’ their authentication to the firebase service, rather than handle it themselves.

Firebase offers a javascript SDK that provides the ability authenticate via the tried and true email / password combo, or any one of the third-party supported auth providers (which can be configured in the firebase console).

After using one of the built-in methods the client javascript SDK provides to send an authentication request to Google.
if the credentials are valid, the response the client receives back will include a “fire-token”. It will look something like this:

For basic authentication, we're interested in the idToken in the credentials object. This fire-token is a JWT token, encrypted via the RS256 algorithm.

If you have a custom backend you're going to want to save this token to local storage on the client side, and send it along with requests for resources on your backend that require authentication.

After sending the fire token to the backend, you're going to want to decode it. There is SDK support for decoding the fire token for some languages. Unfortunately, if your backend is rails, you're going to have to do it yourself.

The decoded token will look something like this:

Header Info

Data Payload

To verify the fire token, first decode it using a standard JWT library for your language. Then you will need to perform some validations. Taken directly from the firebase docs:

In Part 2, I will go over each of these validations in more detail.

Until Then.

A Few Thoughts About Authentication

Jason M — Tue, 11 Feb 2020 21:28:59 +0000

Most people would prefer to login via an existing service they use – for example, google, facebook, twitter etc. – rather than sign up for a new service. And often new potential users will not choose your service precisely because they don’t want to bother with the hassle of registering and keeping track of one more account, since you don’t offer an authentication option they currently use.

Of course, if you have a truly unique service – something that none of your competitors provide – then you’re likely to be okay. But most apps have competitors, and providing third-party authentication login options might mean the difference between customers choosing to make use of your service or another service.

The upshot is that you should always provide login options via federated companies like Google and Facebook. However, as an independent developer, or a developer on a small team, there are many options related to the implementation of third-party authentication.

We can divide the potential options into three broad categories (1) build from scratch (2) use an authentication library / framework, (3) use an authentication service.

(1) certainly offers the most flexibility and freedom with respect to design and implementation at every stage of the authentication flow, but it’s probably not a feasible option for a lone developer or a small team – as they say, there’s no need to re-invent the wheel.

(2) Can be a good choice. There are a number of authentication libraries (e.g., passport for Express, Devise for Rails) that are built to flexibly incorporate new login ‘strategies’. For example, you could build a strategy that makes use of the Facebook login API so that users can authenticate and sign up for your application via the OAuth protocol. If your application uses only one or two strategies, then this may be a solid choice. However, the more strategies incorporated into your application, the greater the time needed for both setup and maintenance.

After all, sometimes authentication and authorization APIs change, or become deprecated for certain services like Facebook login. This means you may very well have to go back and make changes to the strategy that dealt with that API.

(3), authentication as a service, delegates or outsources the bulk of authentication and authorization code to a third-party. Firebase Authentication is a popular option in this category. Firebase will provide secure login via password / username, popular federated providers (facebook, google, twitter etc), or by phone number / email. Firebase Authentication also handles password retrieval via email and phone text.
To make use of Firebase Authentication in a full-stack application requires implementing a javascript Firebase UI component, which handles all of the business logic associated with the user logging in. The user will receive a firebase key. This key needs to go in the headers of any requests to your backend the user’s actions generate. On the backend, the token can be decoded either by (1) using Firebase’s sdk for your language, or (in case your backend isn’t supported), (2) make use of one of the many jwt libraries to extract the relevant information.

Firebase may be the best choice for small teams and independent developers because it allows them to focus on development the meat of their application, rather than dealing with the hassle of authentication.

However, there are potential dangers associated with using full-featured services like this. If the service shuts down or changes it’s feature-set in an undesirable way, you will have no control over it, and may have to go back to the drawing board and adopt a different authentication solution.

A Beginner's guide to examining .CSV data in R Studio

Jason M — Tue, 21 Jan 2020 06:26:19 +0000

These days, there are tons of options available for exploring datasets. One of my favorite environments is R Studio. It's free, open-source, and powerful. R Studio is an IDE for R, a popular veteran programming language, tailored toward data analysis and display. R has thousands of packages which are particularly useful for data analysis, with specialized functions for a variety of scientific disciplines.

In this article, we will learn how to convert a .csv file into a data frame in R Studio, and explore the data via the data frame's built-in capabilities.

Go ahead and download and install the latest version of R for your operating system, and then install R Studio.

Now that you have R Studio installed, the first thing we're going to do is install a handy general purpose library for manipulating data in R.


install.packages("dplyr")

We will need some sample data in .csv form. You can use whatever .csv file happens to be hand (there are plenty available for free on the internet). I grabbed a .csv file with 10k records, see the link here:

http://eforexcel.com/wp/wp-content/uploads/2017/07/10000-Sales-Records.zip

The basic ingredients are in play, now we need to load our .csv frame into R.

First, check our R Studio working directory. In the R Studio console, type

getwd()

My directory is documents, so I'm going to place my .csv file my documents folder. Then, I will go ahead and load that .csv file, and convert it into a native R data frame.

my_records = csv.read("my_records")

Now, my data is living in a data frame. This means that I get access to a lot of handy methods.

To view the number of rows

 nrow(my_records)

To view the number of columns

 ncol(my_records)

To view the column names

 colnames(my_records)

To view the first 10 rows of data

  head(my_records, 10)

To view the last 10 rows of data

  tail(my_records, 10)

To get the sum of the values in a column, by column name

  sum(my_records['Total.Profit']

Sample 5 random rows

  dplyr::sample_n(my_records, 5)

Filter data frame by column values, where Total Cost is greater than 1000

  dplyr::filter(my_records, Total.Cost > 1000)

Remove Duplicate Rows

  dplyr::distinct(my_records)

Select top 5 records, sorted by Total.Cost

  dplyr::top_n(my_records, 5, Total.Cost)

Average of Total.Cost

  dplyr::summarise(my_records, mean(Total.Profit))

Min value in column Total.Cost

  dplyr::summarise(my_records, min(Total.Profit))

Max value in column Total.Cost

  dplyr::summarise(my_records, max(Total.Profit))

Ensuring Immutability in Redux Reducers: Tips for Beginners

Jason M — Mon, 30 Dec 2019 17:02:40 +0000

The front-end for web applications has become increasingly complex, and each year there seem to be more sophisticated data structures, more variables, and more dependencies. While this complexity provides a richer user experience, it can lead to a headache in terms of maintenance and debugging for developers.

Fortunately, along with the difficulties increased complexity has brought us, we've been given a few wonderful tools to deal with it. One of these tools is called Redux. Redux allows us to manage the data which underlies our web application's UI in an effective manner by (1) making sure that data lives in one location, and (2) enforcing a single process for updating that data.

In Redux, the data lives in the store, a plain javascript object that can take many forms, depending on the different kinds of data your application uses. Here's a simple example:


const store = {
  authors: [
    {
      name: "Robert Jordan",
      id: "1",
      books: ["16"]
    },

    {
      name: "Stephen King",
      id: "6",
      books: ["2"]
    }
  ],

  books: [
    {
      name: "the eye of the world",
      id: "16",
      authors: ["1"]
    },

    {
      name: "the shining",
      id: "2",
      authors: ["6"]
    }
  ]
};

In the above example, the store has two kinds of data for the application, books and authors. In the Redux system, each of these pieces of data will have a separate Reducer function which is responsible for handling updates for that piece of data. The reducer for books might look a little bit like this:


import { ADD_BOOK, DELETE_BOOK } from "../actions/index.js";

const booksReducer = (state = [], action) => {
  switch (action.type) {
    case ADD_BOOK:
      return [...state, action.payload];

    case DELETE_BOOK:
      return state.filter(book => book.id != action.payload);

    default:
      return state;
  }
};

export default booksReducer;

Any update that is going to happen to the books array in the store will be done through this booksReducer function. This reducer takes the existing state (in this case, the books array), and a redux action object as arguments. The action object might look like this:


{
    type: ADD_BOOK,
    payload: {
     id: 7,
     name: "Robin Hobb",
     books: ["456", "27"] 
    }   
}

The action object tells the reducer function what sort of thing to do with the accompanying payload information. So, this action will be used to update the store with the new book, in the switch statement for the ADD_BOOK case.

However, whatever action happens to be passed to a reducer function, it's incredibly important that any work done inside the function does not mutate the original state, but instead returns a new altered copy of the data. Violating this principle could very well lead you down a horrible rabbit hole of debugging.

But there are a number of options available to decrease or eliminate the likelihood of accidentally causing mutations in your data inside your reducer functions.

For each of your reducers, for each case or possibility, write a test to make sure no mutations have occurred.

The easiest way to structure this test is just to use a deep-copy library, to copy your state before applying the reducer function to the original state. Then, call the reducer function, and using deep comparison testing (which most test frameworks, such as mocha, will have), make sure the returned state is deeply equal to the original state.

Using some simple tests in this way, you can find out if any of your reducer functions are slipping some unexpected mutations.

Deep-copy your state inside the reducer function before doing any work on it. Then return the altered copy.
Use a library like Immer or Immutable that has custom, immutable objects which don't let you mutate state.

Option 1 is always a good idea, since it can never hurt to have a few more tests, and the time writing the tests could very well save you a lot more time debugging code in the future. Option 2 will ensure that no mutation occurs, but straight up deep copying before doing any work in the reducer is wasteful from a performance perspective, so should be avoided on larger projects.

Option 3 will ensure immutability, but it will also require you to learn another library, and introduce another dependency into your project. Some of these libraries are easier to work with than others, so if you're going to take this route, I suggest reading up the tradeoffs between the popular immutable libraries like Immer and Immutable.