DEV Community: Miklos Bertalan

What Do You Think About the Virtual DOM?

Miklos Bertalan — Mon, 25 Feb 2019 16:55:54 +0000

A few things are becoming de-facto solutions in JavaScript with a lot of tutorials but without much discussion about the practical benefits and reasons. The goal of this series is to talk about these topics.

The rules:

Speak about the whys, not the hows. It's okay to include a few favorite libs and patterns but it should not be the main focus of your comment.
No Googling! I am interested in Your opinion, experience, anecdotes, and gut feelings.
Your comment might get linked or quoted in the weekly summary if you are not asking otherwise. I never quote comments in a negative context.

This week's topic is the Virtual DOM

Do you prefer cross-platform vDOM implementations or Progressive Web Apps? Are these two substitute or complementary?
Do you prefer JSX and CSS-in-JS or the old-school HTML way?
Did you ever have issues with the extra abstraction layer of a vDOM? I am curious about situations where you wanted to do something - that you could do with vanilla DOM - but was blocked by the vDOM layer.
Do you feel like vDOM based frameworks are faster? Can you mention a case where you experienced speed differences?
Whatever pops into your mind about the Virtual DOM.

All comments are welcomed, there is no wrong answer!

Your Thoughts About Types

Miklos Bertalan — Sat, 23 Feb 2019 09:57:51 +0000

This week 7 devs made 11 comments about types. Big thanks to all of you!

What Do You Think About Types?

Miklos Bertalan ・ Feb 18 '19

#programming #discuss #javascript #typescript

My Impression

Most commenters favored statically typed languages with type inference which is not a huge surprise.

They argued that types help in auto-completion, documenting interfaces, and catching errors at compile-time. I have to agree about auto-completion but I think interfaces can be documented with decent naming too. I - and some other devs - also boasted that we never ran into type related errors in JS until someone threw in the good old "Undefined is not a function".

Most contra-side commenters mentioned the extra code as the biggest disadvantage of types. They also mentioned reduced flexibility, although I didn't really get answers for my question about cases where changing the type of something helped. I feel like most people think of the weakly typed nature of JS as a time saver, rather than a feature.

Ultimately you managed to make me curious about types. I tried to avoid them because of the extra bloat but maybe I played with the wrong code bases and became biased. I got tired of reading and writing obvious types but I am now excited to try how well a modern type system with inference can help me. A comment about pattern matching in ReasonML piqued my interest the most. I think I will start there.

Thanks for reading!

Next week's topic will be the Virtual DOM. See you on Monday!

What Do You Think About Types?

Miklos Bertalan — Mon, 18 Feb 2019 17:15:48 +0000

I accidentally posted this on Sunday for a short time, just after promising to continue as a weekly Monday series. In case you saw that post or commented on it, I'm sorry. This is the final republished version.

The rules:

Speak about the whys, not the hows. It's okay to include a few favorite libs and patterns but it should not be the main focus of your comment.
No Googling! I am interested in Your opinion, experience, anecdotes, and gut feelings.
Your comment might get linked or quoted in the weekly summary if you are not asking otherwise. I never quote comments in a negative context.

This week's topic is Types

Do you prefer strongly or weakly typed languages?
Do you have a favorite language type system wise? What makes it better than the rest?
Can you mention situations when using types caught early errors for you?
How does TypeScript relate to group projects? Does it make the barrier of entry and cooperation simpler or more difficult compared to vanilla JS?
Whatever pops into your mind about types.

All comments are welcomed, there is no wrong answer!

Your Thoughts About Immutable Data

Miklos Bertalan — Fri, 15 Feb 2019 14:32:03 +0000

This week 8 devs made 14 comments about immutable data. Big thanks to all of you!

What Do You Think About Immutable Data?

Miklos Bertalan ・ Feb 14 '19 ・ 1 min read

#programming #discuss #javascript #react

My Impression

In general, you favored immutability over mutations and I was the sole 'antagonist' of the thread. There were two distinct uses cases mentioned.

Some of you wrote about immutability as a way of thinking and building whole apps. Unsurprisingly, these comments leaned towards functional programming and mentioned clear data flow and increased code quality as benefits in exchange for added complexity. A commenter quite nicely described these apps as 'data flowing through a pipe of transformations' and mentioned that badly implementing this model can make things unnecessarily complex.

I have to agree with this, embracing this mindset is not an easy task. Don't give up or judge early if it seems messy on the first try, but keep trying until it makes sense.

Others brought up stories where locally applied immutability helped them. In these cases, immutability fixed issues with unexpected mutations of long living objects. My favorite example was a story of mutating events, which the event bus reused later without mentioning this in the docs. Moral of the story: you never know who else keeps references to your objects, always be suspicious towards third-party libs if you work with mutable data.

On the practical side, you mentioned testing, memoization, and time travel as areas where immutability really shines.

As the contra team, I mentioned the strictness as the biggest turn-off. I like to 'hack around' and I usually feel bad when I am forced into a set of best practices. The example I gave was about a (mutable) state management lib that I maintain. A big chunk of the issues are about very basic operations - like getting / settings values or applying (async) side effect. I always explain to simply use obj.prop, obj.prop = value, and async functions which the issuers are already familiar with. They are too afraid to even try them though because of their functional background.

Ultimately I think all of the comments were high quality and constructive. I was also hoping for some junior opinions though. Your comments matter, don't be afraid to express your initial thoughts, ideas, enthusiasm, or frustration.

About the Future

This was the first post of the series and I realized I will have to change a few things:

I tried to avoid direct quoting in this summary but feel free to PM me if I should remove something. Next week I will add a disclaimer about the possibility of linking / quoting comments. I will never quote anybody in a negative context.
In the future, I will bring up topics on Mondays and write summaries on Fridays. Sorry for the short commenting window this week.

Next week's topic will be types. See you on Monday!

What Do You Think About Immutable Data?

Miklos Bertalan — Thu, 14 Feb 2019 08:29:04 +0000

The rules:

Speak about the whys, not the hows. It's okay to include a few favorite libs and patterns but it should not be the main focus of your comment.
No Googling! I am interested in Your opinion, experience, anecdotes, and gut feelings.

This week's topic is Immutable Data

Why is it so popular?
When do you use it? Does it belong to the back-end, the front-end or both? Do you use it together with specific patterns or tech stacks?
Do you use it because it's your stack's best practice? Do you consciously choose a stack the relies on immutable data?
Did you ever have issues with mutable data?
Whatever pops into your mind about Immutable Data.

All comments are welcomed, there is no wrong answer!

JavaScript: The Fun Parts

Miklos Bertalan — Tue, 12 Feb 2019 17:21:52 +0000

JavaScript is evolving rapidly with a bunch of yearly additions. Some of them never reach the spotlight, others get forgotten or deprecated. Let's put these into increasingly hacky editable code sandboxes. The goal is to make you play with occasional horror on your face.

The examples are taken from real libraries or apps that I have written over the years. The last few are controversial though, and I do not encourage you to use them in your code.

Finally

I usually use finally when I have to wrap other devs' functions with some extra logic. finally does this without messing with the original behavior - like return values or thrown Errors.

This example instruments the passed function with performance measurements.

function measure (fn) {
  const start = Date.now()
  try {
    return fn()
  } finally {
    console.log(`${fn.name} took ${Date.now() - start} ms`)
  }
}

WeakSet and WeakMap

These two provide truly private properties (unlike Symbols). I use them when I have to append some metadata to others' objects. Directly mutating these would be bad manners, plus you get screwed if the object is frozen.

This example stringifies the passed object and caches the result. The memoization speeds up the operation and the WeakMap usage avoids object pollution and memory leaks.

const cache = new WeakMap()

export default function stringify(obj) {
  let result = cache.get(obj)
  if (!result) {
    result = JSON.stringify(obj, null, 2)
    cache.set(obj, result)
  }
  return result
}

Proxy

Proxies can tweak language behavior. Most of the time I use them to extend the language and occasionally I use them completely change some default behavior.

This reactive example lets you create observables and reactions. A reaction automatically re-runs when an observable - used inside it - is mutated. The snippet is extremely oversimplified but some additional coding can take it pretty far.

let runningFn
const reactions = new WeakMap()

export function observe(fn) {
  runningFn = fn
  try {
    return fn()
  } finally {
    runningFn = undefined
  }
}

export function observable(obj) {
  return new Proxy(obj, {
    get(target, key, receiver) {
      runningFn && reactions.set(target, runningFn)
      return Reflect.get(target, key, receiver)
    },
    set(target, key, value, receiver) {
      Reflect.set(target, key, value, receiver)
      const reaction = reactions.get(target)
      reaction && reaction()
    }
  })
}

New Function

new Function() is similar to eval but it creates functions in the global scope, which is outside of any 'strict mode' declarations. We will abuse this fact soon.

This example gets the global object - regardless of the platform - which is currently trickier than it should be. It is also used in the ES2019 globalThis proposal polyfill.

const globalThis = new Function('return this')()

This won't work if you have CSP set up for your page.

With

with extends the scope chain for a statement. Sadly, it is deprecated and it won't work in strict mode - which includes ES6 modules. A few tricks can save the day though.

This example lets you write Vue or Angular like template files and renders them in the context of the passed state.

export default function compile(template) {
  return new Function("state", `with (wrap(state)) { return \`${template}\` }`)
}

window.wrap = state => new Proxy(state, {
  has: () => true
})

It tweaks with behavior with the following tricks:

It uses new Function() - instead of eval - to create functions in the global scope. The global scope is outside strict mode so with works there.
It uses Proxies to tweak with behavior a bit. Normally with extends the scope chain and does not replace it completely. When a property is not found on the passed object it will search for it in the next scope - in our case the global one. We do not want the global scope to leak into the template so we have to trick with into thinking that every possible property is present on the passed object. This is pretty simple with the has Proxy trap.

Everything Together

We accidentally created a blazing fast lightweight MVC framework along the way.

Please check the repo here and don't forget to leave a star!

I hope you found some time to play with the sandboxes. Leave a comment if you created something crazy.

Thanks for reading!

Code smart, not hard

Miklos Bertalan — Wed, 06 Feb 2019 16:42:08 +0000

A bunch of ideas for developers working on large production apps.

Average App Anatomy

To reach the widest possible audience I will use a fairly common setup for the demonstration. Our average app ...

has a static landing page with some marketing pitch.
has some public pages, at least a login and a register.
has a handful of private pages.
uses JWT token for authentication.
is written in React with redux, react-router and axios.
is bootstrapped with create-react-app.

I work at a consulting company and this is what comes around most often. Hopefully you can apply the below ideas to your preferred stack too.

Tip #1: Have a solid API layer

The api should handle everything networking related.

Avoid duplicating URLs and headers, use a base API instance instead.
Handle authentication here. Make sure to add the auth token to both localStorage and the base API instance.
Use API interceptors for generic fallback behaviors - like global loading indicators and error notifications.

import axios from 'axios'
import store from '../store'
import { startLoading, stopLoading, notify } from '../actions'

const JWT_TOKEN = 'JWT_TOKEN'

// have a base api instance to avoid repeating common config - like the base URL
// https://github.com/axios/axios#custom-instance-defaults
const api = axios.create({
  baseURL: process.env.REACT_APP_API_URL,
  timeout: process.env.REACT_APP_API_TIMEOUT
})

// add the Auth header to the base API instance once here to avoid repeated code
if (localStorage.getItem(JWT_TOKEN)) {
  const token = localStorage.getItem(JWT_TOKEN)
  api.defaults.headers.Authorization = `Bearer ${token}`
}

// keep networking logic - like handling headers and tokens - in the network layer
export function login (token) {
  api.defaults.headers.Authorization = `Bearer ${token}`
  localStorage.setItem(JWT_TOKEN, token)
}

export function logout () {
  delete api.defaults.headers.Authorization
  localStorage.removeItem(JWT_TOKEN)
}

// handle generic events - like loading and 500 type errors - in API interceptors
api.interceptors.request.use(config => {
  // display a single subtle loader on the top of the page when there is networking in progress
  // avoid multiple loaders, use placeholders or consistent updates instead
  store.dispatch(startLoading())
  return config
})

api.interceptors.response.use(
  resp => {
    store.dispatch(stopLoading())
    return resp
  },
  err => {
    store.dispatch(stopLoading())
    // if you have no specific plan B for errors, let them be handled here with a notification
    const { data, status } = err.response
    if (500 < status) {
      const message = data.message || 'Ooops, something bad happened.'
      store.dispatch(notify({ message, color: 'danger' }))
    }
    throw err
  }
)

export default api

Tip #2: Keep the State Simple

Since loading and generic error handling is already covered by the API, you won't need to use full-blown async actions. In most cases, it is enough to cover the success event.

action.js

import articlesApi from '../api/articles'

const LIST_ARTICLES = 'LIST_ARTICLES'

export function listArticles () {
  return async dispatch => {
    // no need to handle LIST_ARTICLES_INIT and LIST_ARTICLES_ERROR here
    const articles = await articlesApi.list()
    dispatch({ type: LIST_ARTICLES, articles })
  }
}

reducer.js

import { LIST_ARTICLES } from '../actions/articles'

export function articles (state = [], { type, articles }) {
  switch (type) {
    case LIST_ARTICLES:
      return articles
    default:
      return state
  }
}

You should only handle init and error events when you have a specific plan B.

Tip #3: Keep Routing Simple

Implementing a correct ProtectedRoute component is tricky. Keep two separate router trees for public and protected pages instead. Login and logout events will automatically switch between the trees and redirect to the correct page when necessary.

import React from 'react'
import { Switch, Route, Redirect } from 'react-router-dom'

// isLoggedIn is coming from the redux store
export default App ({ isLoggedIn }) {
  // render the private routes when the user is logged in
  if (isLoggedIn) {
    return (
      <Switch>
        <Route exact path="/home" component={HomePage} />
        <Route exact path="/article/:id" component={ArticlePage} />
        <Route exact path="/error" component={ErrorPage} />
        <Redirect exact from="/" to="/home" />
        <Route component={NotFoundPage} />
      </Switch>
    )
  }

  // render the public router when the user is not logged in
  return (
    <Switch>
      <Route exact path="/login" component={LoginPage} />
      <Route exact path="/register" component={RegisterPage} />
      <Redirect to="/login" />
    </Switch>
  )
}

The above pattern has a well-behaved UX. It is not adding history entries on login and logout, which is what the user expects.

Tip #4: Init the App Properly

Do not render anything until you know if the user is logged in or out. Making a bold guess could result in a short flicker of public/private pages before redirecting to the correct page.

import React from 'react'
import ReactDOM from 'react-dom'
import App from './App'
import store from './store'

// do not render the app until we know if there is a logged in user or not
store.dispatch(getMe()).then(renderApp)

function renderApp () {
  ReactDOM.render(<App />, document.getElementById('root'))
}

getMe() should call the /me endpoint which returns the logged in user or a 401 (Unauthorized) error code. Checking for a JWT token in the localStorage is not enough, the token might be expired which could result in an infinite redirect loop for the user.

export function getMe (data) {
  return async dispatch => {
    try {
      const user = await userApi.getMe(data)
      dispatch({ type: LOGIN, user })
    } catch (err) {
      userApi.logout()
    }
  }
}

Tip 5: Use the Landing Page

Returning users will already have some interest in your product and a cached app in their browser. Newcomers won't, and they will judge quickly.

Server Side Rendering your whole app can give a nice first impression, but it is one of the toughest techs out there. Don't jump on that train just yet. Most of the time you can rely on a simple heuristic instead: newcomers will most likely start on your landing page.

Just keep your landing page simple, static and separate from your app. Then use preload or HTTP/2 push to load your main app while the user is reading the landing page. The choice between the two is use-case specific: go for prefetch if you have a single big bundle and go for HTTP/2 push in case of multiple small dynamically named chunks.

I hope I could teach a few new tricks! If you got so far, please help by sharing the article. I may create a second one about creating reusable components if this one gets enough love.

Thanks!

A somewhat tricky hook usage

Miklos Bertalan — Mon, 04 Feb 2019 19:25:27 +0000

I recently updated a React state management library, hoping to reduce its API from two wrapper functions into a single hook. I did not succeed but I still ended up with something nice. Here is why and how.

The starting point

The library had the following API for dealing with global state

import React from 'react'
import { store, view } from 'react-easy-state'

const count = store({ num: 0 })
const increment = () => count.num++

export default view(() => <button onClick={increment}>{count.num}</button>)

... and local state.

import React, { Component } from 'react'
import { view, store } from 'react-easy-state'

class Counter extends Component {
  counter = store({ num: 0 })
  increment = () => counter.num++

  render() {
    return <button onClick={this.increment}>{this.counter.num}</button>
  }
}

export default view(Counter)

Initially, I hoped to reduce the API to something like below.

import React from 'react'
import useStore from 'react-easy-state'

export default function Counter () {
  const counter = useStore({ num: 0 })
  const increment = () => counter.num++

  return <button onClick={increment}>{counter.num}</button>
}

Notice how the view HOC is gone in this failed experiment.

The issues

State management libs are expected to optimize re-renders with shouldComponentUpdate or memo by default. This kind of render bailout can not be done and should not be done with hooks.
Some state management libraries need to know details about the components - like what props do they expect or what data do they use from elsewhere. Hooks are not wrapping the components, so they can not provide these kinds of higher level information.
A useStore hook is nice for local state in function components but it does not work for global state and local state in class components.

All of the above can be solved with Higher Order Components. Hooks are still needed to enable local state with function components though.

The second iteration

After some tinkering and prototyping, I ditched the idea of reducing the API into a single hook but I tried to not extend it with new functions at least. I succeeded this time through a somewhat unorthodox hook usage.

I overloaded the store function to behave like a hook when it is called inside a function component but keep its original behavior otherwise. As a result, I got this syntax for local state

import React from 'react'
import { view, store } from 'react-easy-state'

export default view(() => {
  const count = store({ num: 0 })
  const increment = () => count.num++

  return <button onClick={increment}>{count.num}</button>
})

... and for global state.

import React from 'react'
import { view, store } from 'react-easy-state'

const count = store({ num: 0 })
const increment = () => count.num++

export default view(() => {
  return <button onClick={increment}>{count.num}</button>
})

Notice that the only difference is the placement of the state stores.

The implementation

This is a simplified version of the view HOC which toggles the isInsideFunctionComponent flag to true while the wrapped function component is rendering. This could not be done with a hook.

import { memo } from 'react'

export let isInsideFunctionComponent = false

export default function view (Comp) {
  return memo(props => {
    isInsideFuntionComponent = true
    try {
      return Comp(props)
    } finally {
      isInsideFunctionComponent = false
    }
  })
}

The below snippet is a simplified version of the store wrapper. It decides if it should behave like a local or global store based on the isInsideFunctionComponent flag.

import { useMemo } from 'react'
import { isInsideFunctionComponent } from './view'

export default function store (obj) {
  if (isInsideFunctionComponent) {
    return useMemo(() => storeImplementation(obj), [])
  }
  return storeImplementation(obj)
}

If store is called inside a function component it returns a memoized local state store, otherwise it returns a global store.

But ...

It is not called useStore.

The useX naming is just a convention, which can be broken with a good reason. Ergonomic API design is good enough for me.

It is a hook behind an if statement.

If you are familiar with the rules of hooks the if statement likely made you frown, but it is actually there to adhere to the rules not to break them.

Whenever store is called from a function component the isInsideFunctionComponent flag is true and the if block is entered. From the function component's point of view useMemo is not behind an if block, it is called at the correct place every time the component is rendered.

It is magic (aka dirty hack).

This is why I love JavaScript. One can save immense efforts with decent language knowledge and an easy mind. Simpler is better if you know what you do.

react-easy-state is changing language behavior with ES6 Proxies.
I have a lib built around the 'deprecated' with keyword and I think it is great.
I like to use sparse arrays and the delete keyword for storing data (in deduped priority queues).
The React team started throwing Promises.

These kind of 'hacks' are awesome as long as they do not pose edge cases and hidden pitfalls to their users.

If this article captured your interest please help by sharing it. Also, check out the React Easy State repo if you have some state to manage.

Thanks!

React Easy State v6.1.0: Hooks, Improved Batching and StrictMode

Miklos Bertalan — Thu, 31 Jan 2019 14:41:21 +0000

Easy State is a practical state management library for React.

React is changing swiftly these days and the ecosystem has to keep up. Easy State's v6.1.0 update adds hooks support, StrictMode compatibility and batching improvements without any API changes.

Hooks

Thanks to the participants of this issue, the core of Easy State now supports hooks and local state stores in function components. Let's take a look at three variants of the same counter app for a quick demo.

Class with local state

This is the old-school version of local state management with Easy State, which will continue to work after the v6.1.0 update.

import React, { Component } from 'react'
import { view, store } from 'react-easy-state'

class Counter extends Component {
  counter = store({ num: 0 })
  increment = () => this.counter.num++

  render() {
    return <button onClick={this.increment}>{this.counter.num}</button>
  }
}

export default view(Counter)

It creates a local state store as a class property which is unique per component instance. Multiple instances of this counter increment separately.

Function with local state

This version is available with Easy State v6.1.0+ and React v16.8.0(alpha)+ only.

import React from 'react'
import { view, store } from 'react-easy-state'

export default view(() => {
  const counter = store({ num: 0 })
  return <button onClick={() => counter.num++}>{counter.num}</button>
})

Calling store inside a function component creates a local state store which is unique per component instance. Multiple instances of this counter increment separately.

The store function has been improved to behave like a React hook when it is called from a function component.

Function with global state

This version worked before the update and will continue to work after it.

import React from 'react'
import { view, store } from 'react-easy-state'

// a single store is created outside of the component
const counter = store({ num: 0 })
const increment = () => counter.num++

export default view(() => (
  <button onClick={increment}>{counter.num}</button>
))

Global stores are shared between all components. Multiple instances of the above counter increment together.

Performance

This release includes a pretty big core change which deserves some benchmarking. I updated some js-framework-benchmark entries to React 16.8 and rewrote the Easy State implementation to use function components only. These are the results of a 10x benchmark run on my MacBook.

The benchmark is included for good measure, please consider the following points before jumping to conclusions.

These benchmarks do not matter as long as the user gets a smooth 60 fps experience.
Most React projects have not been updated to use hooks yet.
These kind of benchmarks are useful to rule out very slow libraries, but you should not make decisions based on tiny performance differences. I use them avoid adding accidental performance issues with updates.

Other changes

Automatic sync batching was added for native DOM event handlers to improve performance.
Rewrote the batching implementation to use React's unstable_batchedUpdates.
- Components will no longer render twice if a related store and their props are both changed in a single sync batch.
- Components are always rendered in a parent-child order in a single batch.
- The batch function is just an alias of unstable_batchedUpdates.
Fixed a bug with ES6 Maps and Sets, where object values with nested data were not reactive sometimes.
Tests are wrapped with <StrictMode> to guarantee the compatibility with tomorrow's React.
Added a React Native example and test coverage for React Native.
Added typings for the batch function. (Thanks to moritzuehling)
Improved docs.

The future

The most exciting Concurrent React updates are still in the making. Easy State will likely receive another update after the stabilization of ConcurrentMode and the scheduler package, which will let it hook into React's new async scheduler instead of the current custom batching.

If this article captured your interest please help by sharing it. Also, check out the Easy State repo and leave a star before you go.

Thanks!

The Ideas Behind React Easy State: Utilizing ES6 Proxies

Miklos Bertalan — Tue, 23 Oct 2018 12:03:59 +0000

Front-end developers often refer to transparent reactivity — at the core of MobX, Vue or React Easy State — as magic, but there is nothing magical about it. It is based on a very simple idea, which can be demonstrated with the following snippet.

import React from 'react'
import { view, store } from 'react-easy-state'

const notepad = store({
  author: 'Mr. Note Maker',
  notes: []
})

const NotesApp = view(() =>
  notepad.notes.map(note => <Note note={note} />)
)

const Note = view(({ note }) =>
  <p>{note.text} by {notepad.author}</p>
)

You can perfectly define when you expect NotesApp and Note to re-render: when a new note is added or removed and when the author or a note’s text is modified. Luckily this conclusion was not driven by complex human intuition, but simple programmable if-else logic.

If a part of a state store — which is used inside a component’s render— mutates re-render the component to reflect the new state.

Your brain is creating the following ternary relations about properties of objects — used inside render methods.

object	property	component
appStore	notes	NotesApp
notes array	length	NotesApp
note object	text	Note
appStore	author	Note

When a property of an object is modified you subconsciously collect all of the components which belong to that (object, property) pair. Let’s turn this process into code!

The rest of the article assumes you have a basic understanding of ES6 Proxies and React Easy State. If you don’t know what I am talking about, a quick look at the MDN Proxy docs and the React Easy State repo is enough to go on.

Making a Reactive Core

In order to construct the (object, property, component) relations, we have to know which objects and properties do NotesApp and Note use during their renders. A developer can tell this by a glance at the code, but a library can not.

We also need to know when a property of an object is mutated, to collect the related components from the saved relations and render them.

Both of these can be solved with ES6 Proxies.

import { saveRelation, renderCompsThatUse } from './reactiveWiring'

export function store (obj) {
  return new Proxy(obj, traps)
}

const traps = {
  get (obj, key) {
    saveRelation(obj, key, currentlyRenderingComp)
    return Reflect.get(obj, key)
  },
  set (obj, key, value) {
    renderCompsThatUse(obj, key)
    return Reflect.set(obj, key, value)
  }
}

The store Proxy intercepts all property get and set operations and — respectively — builds and queries the relationship table.

There is one big question remaining: what is currentlyRenderingComp in the get trap and how do we know which component is rendering at the moment? This is where view comes into play.

let currentlyRenderingComp = undefined

export function view (Comp) {
  return class ReactiveComp extends Comp {
    render () {
      currentlyRenderingComp = this
      super.render()
      currentlyRenderingComp = undefined
    }
  }
}

view wraps a component and instruments its render method with a simple logic. It sets the currentlyRenderingComp flag to the component while it is rendering. This way we have all the required information to build the relations in our get traps. object and property are coming from the trap arguments and component is the currentlyRenderingComp — set by view.

Let’s get back to the notes app and see what happens in the reactive code.

import React from 'react'
import { view, store } from 'react-easy-state'

const notepad = store({
  author: 'Mr. Note Maker',
  notes: []
})

const NotesApp = view(() =>
  notepad.notes.map(note => <Note note={note} />)
)

const Note = view(({ note }) =>
  <p>{note.text} by {notepad.author}</p>
)

NotesApp renders for the first time.
view sets currentlyRenderingComp to the NotesApp component while it is rendering.
NotesApp iterates the notes array and renders a Note for each note.
The Proxy around notes intercepts all get operations and saves the fact that NotesApp uses notes.length to render. It creates a (notes, length, NotesApp) relation.
The user adds a new note, which changes notes.length.
Our reactive core looks up all components in relation with (notes, length) and re-renders them.
In our case: NotesApp is re-rendered.

The Real Challenges

The above section shows you how to make an optimistic reactive core, but the real challenges are in the numerous pitfalls, edge cases, and design decisions. In this section I will briefly describe some of them.

Scheduling the Renders

A transparent reactivity library should not do anything other than constructing, saving, querying and cleaning up those (object, property, component) relations on relevant get/set operations. Executing the renders is not part of the job.

Easy State collects stale components on property mutations and passes their renders to a scheduler function. The scheduler can then decide when and how to render them. In our case the scheduler is a dummy setState, which tells React: ‘I want to be rendered, do it when you feel like it’.

// a few lines from easy-state's source code
this.render = observe(this.render, {
  scheduler: () => this.setState({}),
  lazy: true
})

Some reactivity libraries do not have the flexibility of custom schedulers and call forceUpdate instead of setState, which translates to: ‘Render me now! I don’t care about your priorities’.

This is not yet noticeable — as React still uses a fairly simple render batching logic —but it will become more significant with the introduction of React's new async scheduler.

Cleaning Up

Saving and querying ternary relations is not so difficult. At least I thought so until I had to clean up after myself.

If a store object or a component is no longer used, all of their relations have to be cleaned up. This requires some cross references — as the relations have to be queryable by component, by object and by (object, property) pairs. Long story short, I messed up and the reactive core behind Easy State leaked memory for a solid year.

After numerous ‘clever’ ways of solving this, I settled with wiping every relation of a component before all of its renders. The relations would then build up again from the triggered get traps — during the render.

This might seem like an overkill, but it had a surprisingly low performance impact and two huge benefits.

I finally fixed the memory leak.
Easy State became adaptive to render functions. It dynamically un-observes and re-observes conditional branches — based on the current application state.

import React from 'React'
import { view, store } from 'react-easy-state'

const car = store({
  isMoving: false,
  speed: 0
})

function Car () {
  return car.isMoving ? <p>{car.speed}</p> : <p>The car is parking.</p>
}

export default view(Car)

Car is not — needlessly re-rendered on speed changes when car.isMoving is false.

Implementing the Proxy Traps

Easy State aims to augment JavaScript with reactivity without changing it in a breaking way. To implement the reactive augmentation, I had to split basic operations into two groups.

Get-like operations retrieve data from an object. These include enumeration, iteration and simple property get/has operations. The (object, property, component) relations are saved inside their interceptors.
Set-like operations mutate data. These include property add, set and delete operations and their interceptors query the relationship table for stale components.

get-like operations	set-like operations
get	add
has	set
enumeration	delete
iteration	clear

After determining the two groups, I had to go through the operations one-by-one and add reactivity to them in a seamless way. This required a deep understanding of basic JavaScript operations and the ECMAScript standard was a huge help here. Check it out if you don’t know the answer to all of the questions below.

What is a property descriptor?
Do property set operations traverse the prototype chain?
Can you delete property accessors with the delete operator?
What is the difference between the target and the receiver of a get operation?
Is there a way to intercept object enumeration?

Managing a Dynamic Store Tree

So far you have seen that store wraps objects with reactive Proxies, but that only results in one level of reactive properties. Why does the below app re-render when person.name.first is changed?

import { store, view } from 'react-easy-state'

const person = store({
  name: { first: 'Bob', last: 'Marley' }
})

export default view(() => 
  <div>{person.name.first + person.name.last}</div>
)

To support nested properties the ‘get part’ of our reactive core has to be slightly modified.

import { saveRelation } from './reactiveWriring'

const storeCache = new WeakMap()

export function store (obj) {
  const reactiveStore = storeCache.get(obj) || new Proxy(obj, traps)
  storeCache.set(obj, reactiveStore)
  return store
}

const traps = {
  get (obj, key) {
    saveRelation(obj, key, currentlyRenderingComp)
    const result = Reflect.get(obj, key)
    if (typeof result === 'object' && currentlyRenderingComp) {
      return store(result)
    }
    return storeCache.get(result) || result
  }
}

The most important section is the final if block between line 15–18.

It makes properties reactive lazily — at any depth — by wrapping nested objects in reactive Proxies at get time.
It only wraps objects, if they are used inside a component’s render — thanks to the currentlyRenderingComp check. Other objects could never trigger renders and don’t need reactive instrumentation.
Objects with a cached reactive wrapper are certainly used inside component renders, since the currentlyRenderingComp check— at line 15 — passed for them previously. These objects may trigger a reactive render with property mutation, so the get trap has to return their wrapped versions.

These points — and the fact that relations are cleaned up before every render — results in a minimal, adaptive subset of nested reactive store properties.

Monkey Patching Built-in Objects

Some built-in JavaScript objects — like ES6 collections — have special ‘internal slots’. These hidden code pieces can't be altered and they may have expectations towards their this value. If someone calls them with an unexpected this, they fail with an incompatible receiver error.

Unfortunately, Proxies are also invalid receivers in these cases and Proxy wrapped objects throw the same error.

To work around this, I had to find a viable alternative to Proxies for built-in objects. Luckily they all have a function based interface, so I could resort to old-fashioned monkey patching.

The process is very similar to the Proxy based approach. The built-in’s interface has to be split into two groups: set-like and get-like operations. Then the object’s methods have to be patched with the appropriate reactivity logic — namely constructing and querying the reactive relations.

A Bit of Intuition

I was a bit overgeneralizing when I stated that the reactive core is made with cold logic only. In the end, I had to use some intuition too.

Making everything reactive is a nice challenge, but goes against user expectations. I collected some meta operations — that people don’t want to be reactive — and left them out of the fun.

none reactive get-like operations	none reactive set-like operations
Object.getOwnPropertyDescriptor()	Object.defineProperty()
Well-known Symbol keyed properties	Well-known Symbol keyed properties

These choices were made by intuition during my usage test rounds. Others might have a different approach to this, but I think I collected a sensible subset of the language. Every single operation in the above table has a good reason not to be reactive.

Conclusion

The reactive core — implemented in this article — is not in the source of React Easy State. In reality, the reactive logic is in a more general library — called the Observer Utility — and Easy State is just a thin port for React. I intentionally simplified this to make it more digestible, but the presented ideas are still the same. I hope you learned something new if you made it so far!

If this article captured your interest please help by sharing it. Also check out the Easy State repo and leave a star before you go.

Thanks!
(This article was originally published on Medium)

Stress Testing React Easy State

Miklos Bertalan — Thu, 18 Oct 2018 08:06:40 +0000

The first part is my usual intro the React Easy State. Skip ahead to the next section if you are already familiar with it.

React Easy State is a transparent reactive state management library with two functions and two accompanying rules.

Always wrap your components with view().
Always wrap you state store objects with store().

import React from 'react'
import { store, view } from 'react-easy-state'

const counter = store({
  num: 0,
  incr: () => counter.num++
})

export default view(() =>
  <button onClick={counter.incr}>{counter.num}</button>
)

This is enough for it to automatically update your views when needed. It doesn’t matter how you structure or mutate your state stores, any syntactically valid code works.

Backing up the claims

It doesn't matter how you structure or mutate your state stores, any syntactically valid code works.

The final sentence of the intro was not a rhetorical statement and I would like to prove it with a simple App.

import React from 'react'
import { view, store } from 'react-easy-state'

const users = window.users = store([])

function UsersApp () {
  return users.map((user, idx) =>
    <div key={idx}>{user.name} <small>{user.email}</small></div>
  )
}

export default view(UsersApp)

This snippet creates a users array and exposes it globally on window.users, then UsersApp maps the array to a simple React view.

We will mutate the users array from the developer console in increasingly exotic ways and see how UsersApp reacts. Hint: it should automatically re-render when users are added, removed or modified in any way.

#1. Warm up: Adding a new user

Let’s start by adding a simple user to the users array and then changing their email address.

users.push({ name: 'Bob', email: 'bob@gmail.com' })
users[0].email = 'bOb1.gmail.com'

Easy State knows that UsersApp iterates the users array during its render and it knows that user.email is rendered for every user. From this, it deduces that UsersApp should re-render after the above state changes.

Try the live demo!

You can follow along with the live example app. Don’t be surprised, it’s a nearly empty page. You can fill it with users from your developer console — as I did.

#2. Dynamic properties

The first example was not that impressive. Let’s see something that is exclusive to ES6, by pasting these lines — one by one — to the console.

users[1] = { name: 'Ann' }
users[1].email = 'ann@windowslive.com'
delete users[1].email

This time Ann was added by users[1] = newUser instead of push and initially, she didn’t have an email. Adding new properties dynamically — like the email — can only be tracked by ES6 Proxies. Older transparent state management libraries won’t re-render the app in these cases.

delete is another operation that was impossible to track until recently. Easy State re-renders the UsersApp if you delete a property which is used during its render.

#3. Property accessors and enumeration

It’s time to take a deeper dive. For this example, we will need some preparation code.

const Dave = {
  name: 'Dave',
  emails: { primary: 'dave@gmail.com' },
  get email () {
    const result = []
    for (const type in this.emails) {
      result.push(`${type}: ${this.emails[type]}`)
    }
    return result.join(', ')
  }
}

Dave is a user with multiple email addresses. A property getter is used to dynamically generate his email list by enumerating the emails object and constructing a string from it.

users.push(Dave)
users[2].emails.secondary = 'dave@risingstack.com'
delete users[2].emails.primary

Easy State knows that Dave’s email is generated from all of the properties in his emails collection. If a new email is added to the collection it re-renders the UsersApp to reflect it. The same happens when an email is deleted or modified.

#4. The final boss: Inheritance

Let’s see what happens if we throw in prototypal inheritance to the mix. This example will also need a preparation script.

const John = {
  email: 'john@gmail.com',
  name: 'John'
}

Object.setPrototypeOf(John, users[1])

John — the new user — inherits his name and email from Ann — the second user.

users.push(John)
delete users[3].name
users[1].name = 'Ben'
users[3].name = 'John Jr.'

If we delete John’s name, it falls back to 'Ann' because of the inheritance.
Then editing Ann’s name changes both Ann’s and John’s name.
Finally, we add an own name for John again.

Easy State re-renders the App after each of these operations — since all of them result in a different view.

Conclusion

The above examples feature basic JavaScript operations and patterns, that most people don’t even consider for state management. I think that part of the reason is the added complexity from third party state management APIs.

By using Easy State you can focus your brain capacity on inventing your personal, reusable and pure JavaScript patterns, instead of learning new APIs and concepts.

If this article captured your interest please help by sharing it. Also check out the Easy State repo and leave a star before you go.

Thanks!
(This article was originally published on Medium)

Practical Patterns with React Easy State

Miklos Bertalan — Tue, 16 Oct 2018 10:05:10 +0000

React Easy State is a transparent reactive state management library with two functions and two accompanying rules.

Always wrap your components with view().
Always wrap you state store objects with store().

import React from 'react'
import { store, view } from 'react-easy-state'

const counter = store({
  num: 0,
  incr: () => counter.num++
})

export default view(() =>
  <button onClick={counter.incr}>{counter.num}</button>
)

This is enough for it to automatically update your views when needed. It doesn’t matter how you structure or mutate your state stores, any syntactically valid code works.

Don’t worry if you are not familiar with Easy State yet, you already know enough to go on. Alternatively, you can check it out here.

State management and beers

Easy State doesn’t care about how you manage your state, it looks out for any kind of state mutations and updates the view when needed. This article is about state management patterns though. Patterns that are beautifully simple, but overshadowed by a myriad of opinionated libraries.

The next sections explore these patterns through a small app, which finds matching beers for your meal. I recommend you to try it out before you continue reading.

Sharing global state between components

React’s state and setState are often enough for managing local state, but big projects tend to need more. Some information is better saved globally.

JavaScript objects are singletons and they can be shared between files with ES6 import and export. This makes them a perfect candidate for storing global state.

import { store } from 'react-easy-state'

const appStore = store({
  beers: [],
  fetchBeers (filter) {
    appStore.isLoading = true
    appStore.beers = [{ name: 'Awesome Beer' }]
    appStore.isLoading = false
  }
})

export default appStore

Notice how the fetchBeers method uses appStore.beers instead of this.beers. It is a neat trick, which makes object methods safe to be passed as callbacks.

Don’t worry about the dummy fetchBeers method yet, we will smarten it up later. The appStore can be imported and used in any file — like the below NavBar component.

import React from 'react'
import { view } from 'react-easy-state'
import SearchBar from 'material-ui-search-bar'
import { LinearProgress } from 'material-ui/Progress'
import appStore from './appStore'

export default view(() =>
  <div className='searchbar'>
    <SearchBar onRequestSearch={appStore.fetchBeers} placeholder='Some food ...'/>
    {appStore.isLoading && <LinearProgress/>}
  </div>
)

We need another component to display the fetched beers. Naturally it also has to import the global appStore to map a view to its beers array.

import React from 'react'
import { view } from 'react-easy-state'
import appStore from './appStore'
import Beer from './Beer'

export default view(() =>
  <div className='beerlist'>
    {!appStore.beers.length
      ? <h3>No matching beers found!</h3>
      : appStore.beers.map(beer => <Beer key={beer.name} {...beer }/>)
    }
  </div>
)

Easy State re-renders the above NavBar and BeerList components when appStore.isLoading or appStore.beers changes.

Async actions

Let’s breathe life into the fetchBeers method. There is not much to change: it should be turned into an async method and it should fetch the beers from an API, instead of faking them.


import { store } from 'react-easy-state'
import * as api from './api'

const appStore = store({
  beers: [],
  async fetchBeers (filter) {
    appStore.isLoading = true
    appStore.beers = await api.fetchBeers(filter)
    appStore.isLoading = false
  }
})

export default appStore

An ideal store is only responsible of state manipulation and nothing else. Abstracting away the view related logic in the components and the networking logic in an API layer is a good practice. This could mean destructuring events in the component's event handlers and handling authentication and headers in a separate API layer.

Our API is a simple one. It has a single function, which fetches matching beers for a passed food.

import axios from 'axios'

const api = axios.create({
  baseURL: 'https://api.punkapi.com/v2'
})

export async function fetchBeers (filter) {
  const { data } = await api.get('/beers', {
    params: { food: filter }
  })
  return data
}

This example uses the Punk API to find beers. Check it out if you need some free data for your coding demos.

Encapsulating local state

Global state is crucial for big applications, but local state can be just as handy: it improves project structure and reusability. It is your responsibility to decide when to use which.

We are still missing a Beer component, which could use some local state to switch between a picture and a description view. Putting a state store object on the component as a property is a simple way of implementing this.


import React, { Component } from 'react'
import { view, store } from 'react-easy-state'
import Card, { CardContent, CardMedia } from 'material-ui/Card'

class Beer extends Component {
  store = store({ details: false })

  toggleDetails = () => this.store.details = !this.store.details

  render () {
    const { name, image_url, food_pairing, description } = this.props
    const { details } = this.store

    return (
      <Card onClick={this.toggleDetails} className='beer'>
        {!details && <CardMedia image={image_url} className='media'/>}
        <CardContent>
          <h3>{name}</h3>
          {details
            ? <p>{description}</p>
            : <ul>
                {food_pairing.map(food => <li key={food}>{food}</li>)}
              </ul>
            }
        </CardContent>
      </Card>
    )
  }
}

export default view(Beer)

Easy State re-renders the Beer component whenever store.details changes. It doesn’t matter if it is a local store or a shared global one, you can even mix the two in a single component.

The details flag toggles between the two views of the beer card. It could also be stored on the beer object itself, but putting it in an isolated local store is a cleaner approach. It stores view related metadata, which should not pollute the real data.

Conclusion

Npm is packed with amazing tools, which simplify front-end development by a huge amount. Never hesitate to use them when you need them, but always think before you install. Sometimes you can be more productive with less tools.

Some of you wouldn’t even call the above snippets patterns. They are just code examples, that most developers are familiar with. Still, they were more than enough for a creating small app.

If this article captured your interest please help by sharing it. Also check out the Easy State repo and leave a star before you go.

Thank you!
(This article was originally published on Medium)