MobX

We are always building new features and replacing old code at StackShare. Lately we have been building out new features for the frontend, and removing a lot of old jQuery code (sorry jQuery but it's time to go).

We've mainly been using React, ES6 and JavaScript on the frontend to build out the components, and we've been slowly removing some legacy MobX and using GraphQL and Apollo for our state management, if we need to control state further than GraphQL and Apollo allows us to we use just plain React with #context , or the new fancy React #hooks🎣 .

As we've moved towards the above tech, its really made smashing out new features and updating legacy code super fast, and really fun!

Some of our existing pages use MobX however we decided to stop using MobX for new work for a few good reasons:

1. It forced us to use an experimental language feature (decorators)
2. We went all-in on @{GraphQL}|tool:3820| and @{Apollo}|tool:5508| to manage our data and local state.

For all the places where we don't store state in Apollo Client, we use plain old React and hooks (useState and useContext). Our first choice in state management it to have all state stored in Apollo keeping local state accurate by using mutation updates, client resolvers, and local cache.

We started rebuilding our dashboard components using React from AngularJS over 3 years ago and, in order to have predictable client-side state management we introduced Redux inside our stack because of the popularity it gained inside the JavaScript community; that said, the number of lines of codes needed to implement even the simplest form was unnecessarily high, from a simple form to a more complex component like our team management page.

By switching our state management to MobX we removed approximately 40% of our boilerplate code and simplified our front-end development flow, which in the ends allowed us to focus more into product features rather than architectural choices.

The front end for Heap begun to grow unwieldy. The original jQuery pieces became difficult to maintain and scale, and a decision was made to introduce Backbone.js, Marionette, and TypeScript. Ultimately this ended up being a “detour” in the search for a scalable and maintainable front-end solution. The system did allow for developers to reuse components efficiently, but adding features was a difficult process, and it eventually became a bottleneck in advancing the product.

Today, the Heap product consists primarily of a customer-facing dashboard powered by React, MobX, and TypeScript on the front end. We wrote our migration to React and MobX in detail last year here.

#JavascriptUiLibraries #Libraries #JavascriptMvcFrameworks #TemplatingLanguagesExtensions