DEV Community: Shreya Dahal

𝙷𝚘𝚠 𝚒𝚜 𝚝𝚑𝚒𝚜 𝚖𝚘𝚗𝚘𝚜𝚙𝚊𝚌𝚎?

Shreya Dahal — Fri, 28 Jun 2019 13:00:06 +0000

Recently I was scrolling through Stack Overflow's Jobs section and an entry caught my eye (posting):

The font of the title caught my attention immediately. At first, I was just curious about what the font was (as I am always looking for my next coding font). I applied my usual strategy for when I see an interesting font on the internet: open Developer Inspector and look at the styles for the font's name.

In this case, the CSS rules said this font must be Arial--but it clearly wasn't.

On a closer look, there was definitely something weird happening. The text was monospace in the browser title and in the inspector as well. So there must be something about the characters themselves that made the browser render it in monospace everywhere.

First hint, the first character was not J:



$0.innerText[0] === 'J' // false

Also, if you tried to get the code points of the characters, something weird happened:



> $0.innerText.charCodeAt(0)
< 55349
> $0.innerText.charCodeAt(1)
< 56953
> $0.innerText.charCodeAt(2)
< 55349

The first and third characters should not be the same.

When I tried to get the total length of the string, I got:



$0.innerText.length() // 74

But counting the characters manually gets you 42. Where were the rest of the 32 characters?

When I looked at the text closer, I realized that (, ), ', -, ; and the spaces were not in the same font as the rest of the characters. If we removed these characters we got a count of 32 (42 - 10).

So that's how it got to 74--the monospace letters were occupying two character spaces: 32 * 2 + 10 = 74. I knew this happened for many Unicode characters, most commonly in emojis. That's why the first and third characters code points were the same.

Now on to figure out what Unicode characters these were specifically.

Some Googling to figure out what these codes meant led me to this awesome website: http://unicode.scarfboy.com

You can enter any Unicode code point and get an explanation for it. I could not find anything when I searched for the codes themselves, but pasting the character directly got me a result.

Turns out the J was actually named MATHEMATICAL MONOSPACE CAPITAL J.

This opened up a whole world of specialized monospace and other fancy characters meant to be used in Mathematical formula.

Resources:

Full list of Mathematical alphanumeric characters:
https://www.unicode.org/charts/PDF/U1D400.pdf

A video explaining why Flag emoji are 2 characters by Tom Scott:
https://www.youtube.com/watch?v=sTzp76JXsoY

A tool to map what you write to these Unicode characters:
https://yaytext.com/monospace/

When do you know the performance bottleneck is not your code, but the infrastructure?

Shreya Dahal — Thu, 15 Nov 2018 04:42:26 +0000

I have cases where we'd see some performance issue with our REST API and start working on optimizing it.

I think the first thing anyone does is blame the code. Maybe we haven't used the SQL queries right? Could we change the algorithm to process the data better? Are we indexing the columns properly?

But at what point do you consider that perhaps it's the infrastructure: should we upgrade the EC2/RDS instance? Add more load-balanced servers?

Upgrading the infrastructure will definitely improve performance, but at a financial cost. We'd always want to get the last bit of performance from the current hardware by changing the software as much as possible, right?

How do /you/ write tests for React components?

Shreya Dahal — Wed, 07 Nov 2018 11:34:17 +0000

I have tried many strategies to go about this. I did snapshot tests for most of the simpler components; but when there is redux and other libraries involved, doing a snapshot test for even a small component turns out to be too much work; unless you shallow render. Then, the only thing you accomplish from the test is whether or not the components render.

The best way to write unit tests is to write the tests first, that way you are only considering what output you need for different conditions and not worried about the implementation. In case of testing functionality of a component, I see tests that simulate button clicks and what not. Do you write the tests after the component is complete? Doesn't it make it harder to write tests for all the cases (your tests tend to get biased by the implementation)? Or do you write them as you are writing the component?

What is your approach to writing tests for the UI? I feel like I am missing something important.

Good resources for learning desktop application architecture so that they can be applied to web applications

Shreya Dahal — Sat, 15 Sep 2018 05:17:07 +0000

I was reading Addy Osmani's Design Patterns book where he talks about the MV* patterns. It was shocking to me how much the original Smalltalk MVC pattern for building desktop application paralleled the Flux architecture and how we work with React/Redux.

Web applications are often thought of as something new that we are just discovering and the ecosystem is, therefore, evolving very fast and new patterns are being discovered.

But it is also quite true that today's web applications are just a natural evolution to the desktop applications we've been building for decades. As such, I believe, it is very important that today's web application developers have access to the learnings from building desktop applications.

Date-ing Javascript

Shreya Dahal — Wed, 20 Jun 2018 17:32:35 +0000

This blog was originally published at Leapfrog Technology.

There have been some gotchas with working with Date in JavaScript that we’ve had to learn the hard way around. I’m hoping to blow your brains in a controlled manner now instead of having it blown later by a nasty bug.

Initializing Date with a string is ambiguous.

Let’s start with an example. Open up the console on Chrome and run this:

new Date('2018-3-14')
// Wed Mar 14 2018 00:00:00 GMT+0545 (Nepal Time)

Nice, it worked. Now, do the same on Safari (or just trust me if you don’t have access to Safari right now):

new Date('2018-3-14')
// Invalid Date

Wait, what!?

The ECMAScript Specification says that calling the Date constructor with a single string argument will create a new Date with the same implementation as that of Date.prototype.parse.

It then goes on to say that Date.prototype.parse will be implementation dependent if the string is not something that can be generated by Date.prototype.toString or Date.prototype.toUTCString.

Basically, if the string you are trying to parse is not in the format given by Date.toString() or Date.toUTCString(), you are screwed.

Chrome just wants to be extra and goes out of its way to support more formats; but what it really does is give the developers a false sense of security that their code works. This has given us enough “b..but… it works on my machine” situations.

Fine, then what formats does new Date() properly support?

That… also depends on what browser you are on. Here is a quote from the specifications:

The contents of the string are implementation dependent, but are intended to represent the Date in a convenient, human-readable form…

Luckily in this case, there is a consensus on using the ISO 8601 date format. It is quite simple and you probably are already using it:

2018–06–17 // Notice it's 06 not 6
2018–06–17T07:11:54+00:00
2018–06–17T07:11:54Z
20180617T071154Z

Lesson 1: Always use ISO 8601 date-time format, everywhere, always. Seriously.

Update
There has been update to the specifications since ES5 that defines ISO 8601 into the JavaScript specs itself and it is no longer just a consensus.

The whole timezone issue.

The Date object in JavaScript internally is just a number storing the number of milliseconds since 01 January, 1970 UTC.

JavaScript Date has a very rudimentary understanding of timezones and day light saving. It kinda knows what the timezone offset of the machine it is running on is and if DST is applied right now (for both of which it relies on the browser, which relies on the OS).

It does not have the capability of figuring out what time it is in different timezones or what timezone a particular Date object is pegged to. Infact, there is no way to peg a Date object to a particular timezone, all the operations on the Date object is based on the local timezone of the system it is running on.

Everything a Date object does is on that internal number of milliseconds it has in each Date object. So the only real influence of timezones is only when we are initializing that internal number.

For example, when you say new Date('2018-04-14') what is the date object supposed to understand? That could be 1520985600000 if that date is in UTC or 1520964900000 if the date is in +05:45 (Nepal Time).

Knowing when JavaScript understands what is crucial to figuring out the timezone issue.

Here is a quick run down of the possibilities:

Date initialized with ISO 8601 date-time string.

const d = new Date('2018-04-14');
d.toUTCString();
// "Sat, 14 Apr 2018 00:00:00 GMT"
d.toString();
// "Sat Apr 14 2018 05:45:00 GMT+0545"

This is the largest culprit to most of the datetime related issues. Consider you take this Date object and do a getDate() on it. What would be the result? 14, right?

d.getDate();
// 14

Here’s the catch: look at the time part in the output of d.toString() above. Since the Date object only works with the timezone of the local system, everything it does on the Date object is based on the local timezone.

What if we ran the same code on a computer in New York?

const d = new Date('2018-04-14');
d.toUTCString();
// "Sat, 14 Apr 2018 00:00:00 GMT"
d.toString();
// "Fri Apr 13 2018 14:15:00 GMT-0400"

And, what date is it?

d.getDate();
// 13

Come to think of it, this is obvious. 2018–04–14 00:00 in London is 2018–04–14 05:14 in Nepal and 2018–04–13 14:15 in New York.

As it turns out, 2018-04-14 was just a short hand for 2018-04-14T00:00:00Z. See the Z at the end? That means that the given date-time is in UTC.

The results are different if we get rid of the Z.

const d = new Date('2018-04-14T00:00:00+05:45');
d.toUTCString();
// "Fri, 13 Apr 2018 18:15:00 GMT"

Which is true, the midnight of April 14 in Nepal is 18:15 of April 13 in London. Still, d.getDate() will give 14 in Nepal, but 13 anywhere west of Nepal.

Lesson 2: Date initialised from ISO 8601 date-time strings are parsed according to the timezone information on the string, but it is initialized into local time.

Date not initialised from strings.

new Date(2018, 3, 14, 0, 0, 0, 0);

Guess what date that is. March 14, 2018? Wrong. That is April 14, 2018. You see, months start from 0 in JavaScript world. But days still start from 1. Don’t ask me why.

But the nice thing is, that is April 14, 2018 in every computer in every part of the world.

When you initialise the Date object directly with the arguments it is always considered that it is in local timezone.

This is your solution for things like birthdays that is just a date and don’t care what timezone it is initialised in. For most other things, if it matters when and where something happened exactly, it might be best to stick with ISO 8601.

But what if you have a date-time that needs to be initialized from UTC? Turn it into an ISO 8601 string? Maybe…, or just use Date.UTC.

// These two are equivalent:
const a = new Date('2018-04-16');
const b = new Date(Date.UTC(2018, 3, 16));
a.toString() === b.toString();
// true

Lesson 3: If you are paranoid or just work with local times, always initialize Date directly with the arguments.

Strings that are not ISO 8601.

As mentioned before, strings that do not confirm to ISO 8601 format are parsed ambiguously between browsers. But the most common implementations are worth discussing.

Chrome supports many kind of formats (it might be worth noting that Node uses the same V8 engine as Chrome so the results are the same):

new Date('April 13') // April 13 2001 Local timezone
new Date('5/13/2012') // May 13 2012 Local timezone
new Date('15/12/2009') // Invalid Date (Finally!)

On Firefox:

new Date('April 13') // Invalid Date
new Date('5/13/2012') // May 13 2012 Local timezone
new Date('15/12/2009') // Invalid Date

Firefox seems to be a bit more strict, but Safari is by far the strictest.

The thing to note here is that all of these are in local timezone, as if they were initialized directly from the arguments.

But there is an exception to that as well. Consider this:

new Date('2018-04-16T00:00:00')

Is that ISO 8601? Almost, but no. There is no timezone part in that string. So this also falls into the ambiguous group.

On Chrome:

new Date('2018-04-16T00:00:00')
// Mon Apr 16 2018 00:00:00 GMT+0545 (Nepal Time)

Parsed as local time.

On Safari:

new Date('2018-04-16T00:00:00')
// Mon Apr 16 2018 05:45:00 GMT+0545 (+0545)

Parsed as UTC.

This can cause a lot of confusion and headache if you’re only testing on Chrome.

I reiterate, only use ISO 8601 format date strings. Always.

Update
The specification for ES5 states that ISO 8601 string without a timezone part should be treated as UTC, but specs for ES6 states that they should be treated as local time. Safari is just slower in implementing the specifications.

NVM, I’ll just use moment.

First, moment is not a silver bullet against every JavaScript Date issue. Second, many of the caveats in the internal Date object still apply to moment.

For example, both of these will give you Invalid Date in Safari, but will work fine on Chrome:

new Date('2018-3-14')
// Invalid Date
moment('2018-3-14')
// Invalid Date

Also, I’ve seen project that have more than half of their bundle size for moment. That may not be something you care about in the beginning but it’s surely coming to bite you in the future, and it might be too late to turn back by then.

I have nothing against moment, I heavily use it — but on the backend without size constraint; I still haven’t found a convincing use case to use it on the frontend. Maybe DateFNS will suffice your use case?

To Conclude.

Bugs related to incorrect assumptions about the Date object are common and everyone will eventually face it. Gaining a better undestanding of how things work underneath and establishing and enforcing best practices are may be the only way around these. We’ve had our share of combing through code and hunting down bugs to find a faulty Date object underneath it all.

Regrets in a 1-year-old React project

Shreya Dahal — Tue, 27 Mar 2018 08:16:19 +0000

The JavaScript ecosystem has become scary. There are over 600,000 packages in NPM to choose from, with over 600 added every day, and the “best practices” are challenged and replaced by the hot new thing at an alarming rate.

It is natural to want to avoid jumping on every new thing and choose what is needed when starting a new project. That is what we did when we started out on a project.

These are the things we regret doing or not-doing from the get-go:

1. Not Using Selectors

We should have never touched the Redux Store without a selector. The reasoning was simple at the beginning: if you need specialized methods to extract data from your store, your store is too complicated. Simplify that instead; hiding that complexity will only fester it.

But we failed to see the other reason why having selectors is essential (and I feel this is not advertised enough): refactoring. Accept it — the store you have designed right now is not the store you will be using a year from now. Requirements change, designs change, new features are added, features are removed; software evolves, and your store needs to evolve with it.

Turns out, having a single interface that defines exactly what is required out of the store makes refactoring simple. The view (even your container components) do not need to know how things are structured in the store, all they care about is what data they receive.

Also, it becomes effortless to write unit tests. As long as the selector returns the same data, you can change the store all you like.

2. Not writing PropTypes for Recompose HOC chains

We heavily use Recompose. Our presentational components are wrapped with a composed chain of Recompose HOCs that build the container component. They were very simple at the beginning; just a Redux connect and a couple of withProps and withHandlers.

The HOC chain looks incredible, data flows down like a waterfall, but happens when you move things around? It is very easy to lose track of what flows where. You could remove or change a prop in one HOC, and not realize some other HOC several components down depended on it.

An easy way to get around this is to define clear PropTypes (or use a type system like Flow or TypeScript) for each HOC. Writing PropTypes on components come easy, and most linters check for this, but writing PropTypes on Recompose HOCs are not that intuitive and, as far as I know, there are no lint rules to check for it. There is no clear best practice for it yet. This just has to be a project convention and needs to be enforced in peer code review.

3. Ceding too much control to a library

“We’re just building a quick MVP to get going. We don’t need to spend much time with fancy designs, let’s just use a popular component library” — that’s how most projects start, and before you know it you are serving thousands of users and guess what, a fancy design becomes a must have.

We started the project with Material UI. It was awesome. You have every component you’ll ever need, you have fancy animations and it is easy to build with. Then, we outgrew our “MVP” phase. We have new complex features that can’t be done with the simple Material UI components. The small performance costs of using inline style start adding up.

Then, the version of Material UI we were using got discontinued. The new version would be a rewrite and would bring much needed performance improvements. All the issues in GitHub for the older version of Material UI were closed.

So we have a relatively large application that is stuck with an old library, with performance issues, that can’t update to the latest version of React.

What could we do? Either stop everything and upgrade to the newer version. But what about all the components that were dropped in the new version? Find new components to replace them and refactor our code to work with those? Or just drop Material UI and write custom components for everything?

We can’t afford to do either of them. We plan to refactor the code in phases to remove larger dependencies, and once it is simple enough, we’ll upgrade to the newer version (once it comes out of beta, that is).

4. Not using CSS-in-JS

As I said, we started with Material UI, and that was enough for us. We rarely had to customize any of the components, and whenever we needed to, we followed the official advice and used inline styles (this is because Material UI internally uses inline styles).

Also, I advocate the horizontal separation of concerns that React proposes and do not like having one component broken down into multiple files (separate CSS and JS files).

The reason we didn’t have CSS-in-JS from the beginning is that we didn’t need it at the time, and whatever little performance cost we added with inline styles was still shadowed by what Material UI was doing. It was also because the CSS-in-JS community conflicted a few ways of doing things and a de facto library had not yet appeared (still hasn’t).

Now that we are migrating away from Material UI and building more UI by-hand, this is becoming more of an issue. We are currently just using CSS because that’s what everyone is comfortable with, but we are increasingly dividing the CSS for each component to make a clear path for future migration to CSS-in-JS.

Final Words

This list is not meant to be an exhaustive list of things to look out for when starting a React project. I’m sure there are plenty of them on the web already. These are the points I don’t see often and have been the most painful for us.

Unit Testing Recompose HOCs

Shreya Dahal — Mon, 08 Jan 2018 06:55:12 +0000

I am a huge fan of recompose. It lets us write pure, functional, “dumb” components, by allowing us to dump all the logic inside any of the huge collection of HOCs it provides. It’s awesome.

I’ve been using this a lot and there’s this thing that has always been bugging me: how do you test them, properly?

On one hand, since the components become truly pure, a bunch of snapshot tests for the different combination of props pretty much covers them.

Simple tests for mapStateToProps, mapStateToDispatch and mergeProps covers connect.

When it comes to an HOC, it gets a little tricky.

One route would be to do a regular snapshot test for the final component that is actually rendered. But isn’t that repeating the tests we wrote for the pure components? Since we know that they behave properly for a given set of props, we don’t really need to worry about them.

The most common use case of an HOC, from what I have personally seen, is that it takes an input from the props, fetches new information or somehow transforms that input and includes the output as props to the next component.

Hence, if we only need to test the behavior of the HOC, what we really care is what set of props it returns for a given set of input props. Or, in case of a redux-based application, what set of actions it dispatches for a given set of input (I haven’t really thought this through for a non-redux application).

Imagine a component that greets the user with the day and weather.

Hello, John! It is a sunny sunday!

Better yet, lets write it:

import React from 'react';
import { compose, withProps } from 'recompose';

import { getFirstName } from '../utils/name';
import { getDayFromDate } from '../utils/date';
import { getHumanReadableWeather } from '../utils/weather';

const Greeter = ({ firstName, day, weather }) => (
  <div>
      Hello, {firstName}! It is a {weather} {day}!
  </div>
);

/**
 * This HOC takes a more crude version of currentUser, date and
 * weather data and maps them to a version that is easily
 * used in the component. That way, the end component is not
 * dependent on the implementation detail or API response format
 * for these information.
 */
export const enhance = compose(
  withProps(props => ({
    firstName: getFirstName(props.currentUser.name),
    day: getDayFromDate(props.date),
    weather: getHumanReadableWeather(props.weather)
  }))
);

export default enhance(Greeter);

What we need to test now is whether or not the enhancer returns the correct props.

<sidenote> This may look like a trivial thing to test. The point is, when doing TDD, the tests are written first and we can't (in most cases) forsee how complicated the implementation will get. </sidenote>

If I didn’t know any better and was forced into writing a test for it, it’d be something like this:

import React from 'react';
import renderer from 'react-test-renderer';

import Greeter from './greeter';

const weatherData = {
  weather: [{
    id: 804,
    main: "clouds",
    description: "overcast clouds",
    icon: "04n"
  }],
  main: {
    temp: 289.5,
    humidity: 89,
    pressure: 1013,
    temp_min: 287.04,
    temp_max: 292.04
  },
  wind: {
    speed: 7.31,
    deg: 187.002
  },
  rain: {
    '3h': 0
  },
  clouds: {
    all: 92
  },
};

it('should render a component with props name, day and weather', () => {
  const greeter = renderer.create(
    <Greeter
      currentUser={{ name: 'Shreya Dahal' }}
      date={new Date(1514689615530)}
      weather={weatherData}
    />
  ).toJSON();

  expect(greeter).toMatchSnapshot();
});

Good ‘ol snapshot testing.

There are many problems with this.

One, we are dependent on what is rendered to infer what our enhancer returned. It just doesn’t sit well with me that we are infering the validity of our logic from a secondary source. A major concern is that the component we rendered may not use all the props passed. This is an issue because the purpose of an HOC is that it could be reused in multiple components; we would have to test the same HOC with multiple components to see the whole picture.

Two, we can’t do TDD this way. Snapshot testing works for components because we don’t really TDD a view, but writing logic is where TDD shines.

One fine evening, I was lazily browsing through recompose’s API docs and saw a method that brought out fantasies in my head. The createSink method:

createSink(callback: (props: Object) => void): ReactClass

Creates a component that renders nothing (null) but calls a callback when receiving new props.

This factory function takes a callback and returns a component that renders nothing but calls the callback every time it receives any props. So if this sink component is enhanced with an HOC, the callback can tell us exactly what props the HOC has passed in.

So we can do something like this to test just the enhancer in the Greeter example above:

import React from 'react';
import renderer from 'react-test-renderer';
import { createSink } from 'recompose';

import { enhance } from './greeter';

it('should render a component with props name, day and weather', () => {
  const sink = createSink(props => {
    // This callback will be called for each set of props passed to the sink
    // We can use `toMatchObject` to test if the given key-value pairs are
    // present in the props object.
    expect(props).toMatchObject({
      name: 'Shreya',
      day: 'sunday',
      weather: 'cloudy',
    });
  });

  const EnhancedSink = enhance(sink);

  renderer.create(
    <EnhancedSink
      currentUser={{
        name: 'Shreya Dahal',
      }}
      date={new Date(1514689615530)}
      weather={weatherData}
    />
  );
});

A simple data in, data out. TDD away!

Now on to HOCs with side effects: HOCs that dispatch actions in their lifecycle.

So there’s an HOC that fetches a given contact and includes it in the props to be consumed down the line:

import React from 'react';
import { connect } from 'react-redux';
import { compose, lifecycle } from 'recompose';

// You'd probably have a proper selector instead
const getContactById = (state, id) => id && state.contacts[id] || {};

const withContact = compose(
  connect(
    (state, props) => ({
      contact: getContactById(state, props.contactId),
    }),
    dispatch => ({
      fetchContact(id) {
        dispatch(contactActions.fetchContact(id))
      },
    })
  ),
  lifecycle({
    componentDidMount() {
      // Fetch details for the given contactId on mount.
      this.props.fetchContact(this.props.contactId);
    },
    componentWillReceiveProps(nextProps) {
      // Fetch details for the new contactId if the contactId prop has changed.
      if (nextProps.contactId !== this.props.contactId) {
        this.props.fetchContact(nextProps.contactId);
      }
    }
  })
);

export default withContact;

How do we go about testing this?

If we need to use connect, it will need to have been wrapped in a Provider with a store. We can use redux-mock-store for that. Then, we can easily extract out a list of all the actions that have been dispatched to the mock store.

Testing actions dispatched in componentDidMount is simple:

import React from 'react';
import renderer from 'react-test-renderer';
import configureStore from 'redux-mock-store';
import { Provider, connect } from 'react-redux';

import withContact from './withContact';
import * as contactActions from '../actions/contactActions';

const mockStore = configureStore([]);

// Component that renders nothing. Used as the end point of an HOC.
const NullComponent = () => null;

it('should dispatch a FETCH_CONTACT action on mount', () => {

  const store = mockStore({});

  const EnhancedSink = withContact(NullComponent);

  renderer.create(
    <Provider store={store}>
      <EnhancedSink contactId={214} />
    </Provider>
  );

  expect(store.getActions()).toContainEqual(
    contactActions.fetchContact(214)
  );
});

Testing componentWillReceiveProps is similar. We can use react-test-renderer's testInstance.update method to rerender the root component with different props, and it will do the right thing: call componentDidMount for new components and componentWillReceiveProps for old components.

it('should fetch a new contact when prop is changed', () => {
  const store = mockStore({});

  const EnhancedSink = withContact(NullComponent);

  const RootComponent = ({ id }) => (
    <Provider store={store}>
      <EnhancedSink contactId={id} />
    </Provider>
  );

  // First mount the component with first props
  const renderInstance = renderer.create(<RootComponent id={123} />);

  // Clear actions that may have been dispatched during mount.
  store.clearActions();

  // Then, change the props
  renderInstance.update(<RootComponent id={456} />);

  expect(store.getActions()).toContainEqual(
    contactActions.fetchContact(456)
  );
});

Nice.

This may seem like a lot of code to test just two lifecycle methods, but these have been deliberately separated like this. The didMount and willReceiveProps tests can go into the same test suite (describe block) and can probably use the same store, EnhancedSink and RootComponent. That would also largely simplify the willReceiveProps block. What I'm saying is there are ways you can do it simpler.

Either way, a little more time and effort put into writing tests (while the code is simpler, or better yet, when the code isn’t even there) can go a long way and is worth it.