Forem: Prodo

Why can’t developers KISS?

Onurbon — Wed, 30 Oct 2019 15:01:24 +0000

Software development has become so complex that it’s almost funny.

I’ve heard many developers praise the “Keep It Simple, Stupid” principle in public, but I’m yet to meet one describing the code they work with as “simple”.

One of my favourite posts of all time, the insightful What’s Awful about Building Software, has already covered nicely what complex software feels like and how it affects our lives. So I’m going to assume that you’ve either read it or experienced some of the pains yourself. But having now spent 10 years building software, including the last 3 years building developer-facing products (to try and simplify programming), I wanted to reflect on the reasons why it is so hard in practice to change our code, our tooling, our culture and the status quo.

Below are 10 reasons that made it to my list, in no particular order:

we have an ego problem — developers can have strong opinions about the right way of doing things, and the right way is their way, regardless of how complex others find it
we suffer from impostor syndrome — some blame themselves for not being smart enough when they should in fact blame the unnecessary complexity that crept into the code
we can be pessimist control freaks — instead of embracing high-level, declarative and automated frameworks, we often prefer the much more complex low-level alternative to remain in full control, just in case we might need this control down the line
we’re particularly snobbish about low-code — those “Enterprise low-code platform” are designed for the “suits” and not for smart people, right? Granted, the vendor lock-in of traditional low-code platforms can be a non-starter, but why isn’t anyone building an open-source platform?
complex tools make us feel smart — think about complex tools such as Kubernetes or Redux with their ~50k stars on GitHub; those are great for large-scale software projects, but you’re not Google, and some of us only use them out of vanity (to feel smart or boost our CVs)
we still confuse code with Maths — yes, good abstractions can be extremely helpful (relational algebra gave us SQL), but there’s nothing simple about functions calling functions calling functions calling functions…
we get very attached to our code — we might have learned about all the problems that come with “code ownership”, but deep down, we’re still territorial and tend to push back when anyone suggests to refactor our own code just to make it simpler
radical innovation is hard and risky — how many technical entrepreneurs will dare building disruptive tools to “simplify software” when Microsoft is worth $1T and controls a big chunk of the developer tools industry, including GitHub?
developers care, but no one else will — it could really help if non-technical colleagues were contributing to the effort of keeping code simple, but that’s hard in practice. How could a PM or a designer tell the difference between simple code or complex code?
it’s all because of Trump and Brexit — just kidding here, but doesn’t everything boil down to politics at the end? It might help if society started to care a bit more about software transparency. Perhaps the complexity of software should even be regulated one day.

Despite all of the above, I personally remain very optimistic that things will eventually change for the better, simply because software has to become simpler to write and maintain. The need for software and the shortage of developers have never been so acute, the low-code space is booming, and VCs have a renewed appetite for dev tools, thus creating new opportunities.

More importantly, and despite all the aforementioned hurdles, there are still many passionate developers out there shipping new open-source solutions to try and fix the complex mess we’re in. If you’d prefer to look at one of those new solutions (instead of just reading me rant about old problems), please consider giving Prodo a spin and discussing it on Slack!

TypeScript Friendly State Management

Jake Runzer — Tue, 29 Oct 2019 10:52:29 +0000

TypeScript allows you to write safer and more robust code, while also improving the developer experience with things like better autocomplete, jump to definition, and type inference. However, setting up and using TypeScript with state management libraries has notoriously been difficult. Things are getting better, but there is still room for improvement. In this article I go over the current state of using TypeScript with Redux, MobX, and Overmind, and discuss what an even better solution would look like.

Existing Solutions

There are several existing frameworks with partial support for TypeScript. In a lot of these cases though, TypeScript is an afterthought and getting it setup is cumbersome and painful.

Redux

Redux has detailed documentation on how to setup TypeScript, but like many other areas of Redux, there is a lot of boilerplate involved. Especially if you want to have async actions using libraries like Thunk or Saga.

Creating actions is one area where the amount of code you need to write for TypeScript is almost double the amount for JavaScript. Let’s take a look at the example from the Redux documentation.

// src/store/chat/types.ts
export const SEND_MESSAGE = "SEND_MESSAGE";
export const DELETE_MESSAGE = "DELETE_MESSAGE";

interface SendMessageAction {
  type: typeof SEND_MESSAGE;
  payload: Message;
}

interface DeleteMessageAction {
  type: typeof DELETE_MESSAGE;
  meta: {
    timestamp: number;
  };
}

export type ChatActionTypes = SendMessageAction | DeleteMessageAction;


// src/store/chat/actions.ts
import { Message, SEND_MESSAGE, DELETE_MESSAGE, ChatActionTypes } from './types'

export function sendMessage(newMessage: Message): ChatActionTypes {
  return {
    type: SEND_MESSAGE,
    payload: newMessage
  }
}

export function deleteMessage(timestamp: number): ChatActionTypes {
  return {
    type: DELETE_MESSAGE,
    meta: {
      timestamp
    }
  }
}

The types file is basically duplicated in the actions file. This means that for every new action you create, you will need to create a new constant, create a new action type interface, and create the action creator. All this and you haven’t implemented any actual logic. This is boilerplate. Type checking reducers is a bit better, except you need to manually type the action and return a value instead of it being inferred.

// src/store/chat/reducers.ts
import {
  ChatState,
  ChatActionTypes,
  SEND_MESSAGE,
  DELETE_MESSAGE
} from './types'

const initialState: ChatState = {
  messages: []
}

export function chatReducer(
  state = initialState,
  action: ChatActionTypes
): ChatState {
  switch (action.type) {
    case SEND_MESSAGE:
      return {
        messages: [...state.messages, action.payload]
      }
    case DELETE_MESSAGE:
      return {
        messages: state.messages.filter(
          message => message.timestamp !== action.meta.timestamp
        )
      }
    default:
      return state
  }
}

The above examples show the effort required to make TypeScript play nice with standard Redux. What if we want async actions? When using Redux thunk you will have thunk actions with the type:

ThunkAction<void, StateType, ThunkExtraArguments, ActionType>

Typing this throughout your codebase, even for smaller apps, makes things much more complicated than they need to be. In one project at Prodo we ended up with the following file:

import * as firebase from "firebase/app";
import { AnyAction } from "redux";
import { ThunkAction } from "redux-thunk";
import { State } from "..";
import { Database } from "../../database";

export interface ThunkExtraArguments {
  firebase: firebase.app.App;
  reactReduxFirebase: any;
  database: Database;
}

export type Thunk<R = any> = ThunkAction<
  R,
  State,
  ThunkExtraArguments,
  AnyAction
>;

export const typedThunk = <T extends string, R>(
  type: T,
  args: any[],
  thunk: ThunkAction<R, State, ThunkExtraArguments, AnyAction>,
): Thunk<R> & { type: T; args: any[] } => {
  (thunk as any).type = type;
  (thunk as any).args = args;
  return thunk as Thunk<R> & { type: T; args: any[] };
};

Even as someone involved in the project from the start, I struggle to understand at a glance what the code is doing. Onboarding employees to the project was difficult because they needed to learn all of this TypeScript overhead.

When connecting React components to the store, the most common pattern I’ve seen is using Props and EnhancedProps .Props is the type for props that will be passed by the parent component and EnhancedProps is the type for props that come from the connect function.

import * as React from "react"
import { connect } from "react-redux"
import { State } from "./types"

interface Props { /* ... */ }
interface EnhancedProps { /* ... */ }

const MyComponent: React.FC<Props & EnhancedProps> = props => (
  /* ... */
)

const mapStateToProps = (state: State, ownProps: Props) => ({
  /* ... */
})

export default connect(mapStateToProps)(MyComponent)

MobX

MobX is currently the second most popular state framework for the web. Up until recently, TypeScript support was very limited when using the inject function. However, the support has been much nicer since mobx-react version 6.0 when it started relying on React hooks.

Defining your store and actions is fully typed.

import { observable, action } from "mobx";
import newUUID from "uuid/v4";

export class Store {
  todos = observable<{
    [id: string]: {
      text: string;
      done: boolean;
    };
  }>({});

  newTodo = action((text: string) => {
    this.todos[newUUID()] = { text, done: false };
  });

  toggle = action((key: string) => {
    this.todos[key].done = !this.todos[key].done;
  });
}

export default new Store();

Observing part of the store in a component is accomplished by creating a useStores hook.

import { Store } from "./types"
import { MobXProviderContext } from 'mobx-react'

export const useStores = (): Store => {
  return React.useContext(MobXProviderContext)
}

and using it in a component wrapped with observe.

import * as React from "react";
import { useStore } from "../store";

const MyComponent = observer((props: Props) => {
  const store = useStores();

  return (/* ... */;
});

There are a few gotchas with this method, but they are well documented on the mobx-react website.

TypeScript support in MobX is much nicer than Redux, but there are other aspects of the library that make it not suitable for all projects, such as when you want time travel debugging and uni-directional data flow.

Overmind

Overmind is another library for managing state that offers a very minimal and friendly API. It is less popular than Redux or MobX, but has strong support behind it. It was developed in TypeScript itself so offers good support. The online editor CodeSandbox has even started to adopt Overmind, TypeScript being one of the main reasons.

There are two approaches you can use when setting up TypeScript for overmind in your project. The first is the declare module approach.

// src/overmind/index.ts
import { IConfig } from 'overmind'

const config = {
  state: {
    count: 0
  },
  actions: {
    increaseCount({ state }) {
      state.count++;
    },
    decreaseCount({ state }) {
      state.count--;
    }
  }
};

declare module 'overmind' {
  // tslint:disable:interface-name
  interface Config extends IConfig<typeof config> {}
}

The benefit of this is that all of the imports coming from overmind are typed to your application. The downside is that you can only have a single overmind instance in your app. Overriding types for a library might also make experienced TypeScript users a bit uncomfortable.

The second and more common approach is explicitly typing everything.

// src/overmind/index.ts
import {
  IConfig,
  IOnInitialize,
  IAction,
  IOperator,
  IDerive,
  IState
} from 'overmind'

export const config = {
  state: { /* ... */ },
  actions: { /* ... */ }
}

export interface Config extends IConfig<typeof config> {}
export interface OnInitialize extends IOnInitialize<Config> {}
export interface Action<Input = void, Output = void> extends IAction<Config, Input, Output> {}
export interface AsyncAction<Input = void, Output = void> extends IAction<Config, Input, Promise<Output>> {}
export interface Operator<Input = void, Output = Input> extends IOperator<Config, Input, Output> {}
export interface Derive<Parent extends IState, Output> extends IDerive<Config, Parent, Output> {}

In both of these approaches, you must type actions explicitly. Unfortunately when you are manually typing something, TypeScript inference is longer used and you have to manually specify the return types.

import { Action } from './overmind'

export const noArgAction: Action = (context, value) => {
  value // this becomes "void"
}

export const argAction: Action<string> = (context, value) => {
  value // this becomes "string"
}

export const noArgWithReturnTypeAction: Action<void, string> = (context, value) => {
  value // this becomes "void"

  return 'foo'
}

export const argWithReturnTypeAction: Action<string, string> = (context, value) => {
  value // this becomes "string"

  return value + '!!!'
}

Using your state in a component can be done by first creating a hook:

// src/overrmind/index.ts
export const config = {
  state: { /* ... */ },
  actions: { /* ... */ }
}

export const useOvermind = createHook<typeof config>()

And using it in your components

import * as React from "react";
import { useOvermind } from "./overmind";

const Counter: React.FC = () => {
  const { state, actions } = useApp();
  return (
    <div className="App">
      <h1>{state.count}</h1>
      <button onClick={() => actions.decreaseCount()}>decrease</button>
      <button onClick={() => actions.increaseCount()}>increase</button>
    </div>
  );
}

What we want

The TypeScript authors have done an amazing job making it fit into the existing JavaScript ecosystem. Community efforts like DefinitelyTyped work really well and allow you to type JavaScript libraries that were created before TypeScript even existed. However, libraries that were designed with TypeScript in mind from the start, offer a more seamless developer experience.

With that in mind, the following are some features we would like to see in a state management framework when using TypeScript.

Type Inference
Framework extensions are fully typed
The initial state is fully typed
Jump to definition works seamlessly

Prodo

Here at Prodo we have taken the ideas above and created our own state management framework. We believe it is a step in the right direction and will allow you to develop applications with the speed of JavaScript and with the security and developer benefits of TypeScript. In comparison to the libraries mentioned above, Prodo has an API most similar to Overmind.

Defining your state is as simple as creating an interface.

// src/model.ts
import { createModel } from "@prodo/core";

interface State {
  count: number;
}

export const model = createModel<State>();
export const { state, watch, dispatch } = model.ctx;

Your initial state is fully typed when you create the store.

import { model } from "./model";

const { Provider } = model.createStore({
  initState: {
    count: 0,
  },
});

This provider is a React context provider and can be used to wrap your root level component.

Actions can be defined anywhere and are fully typed. The following examples are possible by using the Babel plugin.

import { state } from "./model";

const increaseCount = () => {
  state.count++;
};

const decreaseCount = () => {
  state.count--;
};

Components are similarly typed

import * as React from "react";
import { state, watch, dispatch } from "./model";
import { increaseCount, decreaseCount } from "./actions";

export const App = () => (
  <div>
    <button onClick={() => dispatch(decreaseCount)()}>-</button>
    <h1>Count: {watch(state.count)}</h1>
    <button onClick={() => dispatch(increaseCount)()}>+</button>
  </div>);

The above code is from the current version of our framework. We are also experimenting with different syntax and ways of doing state management. A post describing this can be found here.

We have open-sourced Prodo on Github at github.com/prodo-dev/prodo. Please consider giving this repo a star if you like the direction we’re taking. You can also join our Slack community if you want to continue the discussion.

Recording Maintainable Tests

andrejak — Tue, 29 Oct 2019 10:10:21 +0000

Testing your application has indisputable long-term benefits. However, when starting a new project, it can sometimes seem difficult or feel like it’s slowing us down. The longer you wait to take it seriously, the harder it becomes to set up. Wouldn’t it be great to have a fast, frictionless way of adding tests to resolve this dilemma?

Different companies approach testing in different ways. For example, some would have remote QA teams doing all the work manually, some would explore a fully automated approach, or some would record their tests from the browser. There are lots of benefits in the latter approach, but one disadvantage is that you’re always reliant on DOM artefacts, which makes the tests hard to maintain. Test maintenance becomes a known serious issue as the project grows and evolves. Most of these tools are framework-agnostic, which is nice, but we believe there’s benefit in leveraging a specific framework to allow for further automation for the tests to remain maintainable.

Writing tests can feel repetitive, which is often a sign there are parts of it we can automate. Simulating user action sequences by writing long test files doesn’t feel intuitive. Why can’t we just record the journeys and verify that our code changes haven’t broken the flow?

At Prodo, one of our key principles is “make the right thing to do the easiest thing to do”. So we implemented something like that in the initial prototype for our framework. Re-implementing and improving it in Prodo is currently a work in progress. Feedback is more than welcome — please let us know what you think about it.

Stories

In the initial prototype for Prodo, we created a concept of “stories”. It was inspired by Storybook, which is great for visualising tests, but still requires a bit of manual effort to use, and is further complicated if you combine it with frameworks such as Redux.

In Prodo, a story is basically your app with a specified state, and optionally a sequence of actions that brought it there. It’s useful for quickly visualising what your users are likely to see and experience.

For example, in a Todo list you might have stories such as “Empty list” or “List with many items”. In real world applications, common basic stories might be “Logged out” and “Logged in”. You could also have stories per component. For instance, a Todo list item could be “Done”, “Not done”, or “Being edited”. Seeing these side by side can help you ensure your code changes are not breaking the user experience.

You could view, create and update these stories in our developer tools. Alternatively, you could write them as code in your editor, if you prefer.

Testing appearance

“Static” stories (which have state, but no action sequence) can then easily be tested for some basic requirements: does the story render, i.e. not throw an error? Is the (html or png) snapshot of the story still the same as before?

You could easily generate those from the developer tools by ticking a box:

Testing behaviour

“Dynamic” stories, which consist of an initial state and a sequence of actions that then leads to a final state, are a bit more interesting. With these, you could test user flows and verify that actions still result in the same final state, even if you’re changing the underlying code. We called this a “state comparison” test.

To demonstrate, I’ve saved a story of a user adding four todo list items and ticking off one, and here’s what replaying the actions looks like:

In addition to replaying the whole story, there is the option of time travelling between actions and replay from a chosen point:

Let’s say I’m now working on my Todo list app, and I’ve accidentally modified my newTodo action code to add all the items in uppercase. My state comparison test will now fail, and when I start investigating and replay the story action sequence, I will quickly see why:

You could also integrate these tests with your CI. We’ve toyed with the idea of building a GitHub PR bot that would show you the before and after.

Generating actual code

One downside of browser based tests is that they can be quite fragile. For example, if you change the class name or some text inside a button, it can easily break the logic. This is one of the reasons why our goal is to record tests using the devtools and then generate maintainable and stable test code. Since it’ll be in TypeScript, that will help you flag issues and fix tests when you refactor your code. With readable code files it’ll be easy for developers to extend the tests and add more complex logic.

In our prototype, we generated JSON objects for this purpose. However, we realized this had some downsides, such as the fact that we couldn't use TypeScript to catch issues in the tests. Here is an example of a story which adds an item to the ToDo list:

In the official version, we are planning to generate Jest files, which can be typed and run as easily as any other tests. And here's what the generated test code might look like:

What’s next?

In the coming months, we are planning to release similar features in Prodo with a more intuitive interface and an improved user experience. If you liked any of the features in particular, you can join our Slack community to let us know and help us prioritise accordingly. You can also check out our open source GitHub repo (consider giving it a star if you like the direction we’re taking).

Bringing the simplicity of React to your entire stack.

Tom Dawes — Wed, 23 Oct 2019 16:57:36 +0000

As developers, we’ve found that React has been a breath of fresh air in the otherwise very complex world of JavaScript frameworks. After a couple of years of obsessing about making programming more accessible, we’ve now convinced ourselves — and would like to convince you — that the rest of your product stack can and should be just as simple.

In this post, we’ll review why React feels so simple, where we can apply similar principles, and how we plan to make this a reality for everyone.

What makes React just so good?

There are a lot of good things to say about React and its philosophy. For instance, developers would often praise React for being “functional” and “declarative”. But to summarise it in plain English, our view is that React’s simplicity boils down to three things:

It’s simple — Modern React components are just plain functions. They take an input (props, state and context) and output React elements. Developers only have to interact with a minimal API (which is made intuitive through JSX), don’t have to worry about asynchronous behaviour (React will re-render each component as asynchronous behaviour yields updates) and can write very readable code that is easy to integrate with type-checkers such as TypeScript.
It’s automated — Most developers never have to think about the difference between a React element and an HTML element — for all intents and purposes, they’re the same. Developers can write their code to generate React elements and stop worrying about what happens after that. React is quietly handling all of the grunt-work — it determines the minimal set of DOM transformations, commits those changes in a consistent manner, handles the interaction with browser APIs, and ensures that everything gets re-rendered efficiently if anything changes. The developer only has to occasionally step in where React is unable to do all the work by itself (e.g. specifying explicit keys to help with reconciliation).
It’s open — Thanks to its design and its philosophy, React has become a popular and powerful ecosystem. It fits the real-world, rather than trying to force a one-size-fits-all solution to every project. It integrates easily with a range of CSS frameworks, allows developers to extend functionality by combining native hooks together to form custom hooks, and can be generalised beyond web and native applications, to render VR applications, PDF files and loads more. And a new form of composability was recently introduced through React Hooks.

The problem with everything else

Building real-life applications requires a lot more than just visual components — you’ll typically need database connections, API requests, browser feature integration and domain logic.

Technologies like GraphQL have made it easier to move some of the complexity to the back-end and query the data you need directly from your React components. But that’s just to query raw data. This doesn’t help you with the hard technical bits, like managing user sessions, authentication, and front-end state management. Likewise, React Hooks can often simplify data management, but the built-in hooks only offer a concept of local state and provide an injection mechanism for global state frameworks.

So most developers end up adopting a “state management” framework like Redux to manage all of this data in a single place and provide structure around accessing and updating it. But there is very little consistency between how the many redux-* libraries interact — some ship with reducers and custom actions, supplying their own logic, while others use middleware to integrate with existing actions. Some integrate with React directly, using component lifecycles to trigger logic while others rely on manual interaction through react-redux. In fact in most cases, you have to do both.

Most importantly, Redux itself is failing to meet the three criteria which have made us fall in love with React. It’s not simple because you can’t just call functions — you need things like “action creators” and “reducers” just for a basic implementation, and then you need additional abstractions such as “thunks” or “sagas” to deal with more complex behaviours. It’s not automated — in fact, it’s very low-level and requires a lot of boilerplate, even for very simple data transformations. And it is open in principle, but fails to meet the mark in practice because of overly-complex APIs and lack of normalisation.
Thankfully, Redux isn’t the only option and there any many alternatives that sometimes achieve one or two of the targets — but nothing has managed to hit all three.

Thankfully, Redux isn’t the only option and there any many alternatives that sometimes achieve one or two of the targets — but nothing has managed to hit all three.

Our Vision

We believe that the next generation of state management libraries will have to:

manage data with plain and simple functions, both on the client (actions) and server (lambdas);
provide a declarative way to deal with data, leaving the framework to automate when and how to fetch data or manage subscriptions, yet letting you specify what is shown while data is loading; and
be extensible via a plugin system, allowing developers to easily add functionality and integrate with whichever backend technologies are best fit for purpose.

We have built an early implementation of the principles above, which you can find on CodeSandbox here. All of the code snippets below are taken from that project.

You should be able to define updates to a remote database state by writing simple JSON-like mutations:

import { newId } from "./effects"

export const likeMessage = (id: string) => {
  db.messages[id].likes++;
};

export const postMessage = (text: string) => {
  const id = newId();
  db.messages[id] = {
    text,
    author: auth.username,
    likes: 0,
    roomId: state.roomId,
  };
};

And then use your data and actions from any component with zero boilerplate:

export const Message = ({ id }: { id: string }) => {
  const { db } = useData(() => <LoadingSpinner />);
  const { likeMessage } = useActions();
  return (
    <div>
      <h2>{db.messages[id].text}</h2>
      <span>{db.messages[id].likes}</span>
      <button onClick={() => likeMessage(id)}>+1</button>
    </div>
  );
};

Under the hood, a smart framework will automatically connect your components to the store, track which parts of the state are being used and manage the appropriate subscriptions, display any necessary loading spinners (e.g. while data is being fetched asynchronously), and selectively re-render components when needed.

And without the unnecessary abstraction and boilerplate, TypeScript can then easily infer all the types in your code base on a few provided data types.

The progress so far

You can see an experimental, self-contained implementation of the above concepts on CodeSandbox:

We have also open-sourced a more stable version of our production framework at https://github.com/prodo-dev/prodo. The latter includes a lot of functionality that we haven’t discussed here, such as support for streams/subscriptions, time-travelling dev-tools and simplified unit-testing. Please consider giving this repo a GitHub star if you like the direction we’re taking.

Meanwhile, we’re also building a suite of next-generation developer tools to make front-end development more intuitive and automated — for example, by letting you generate tests directly from a GUI, or by automatically generating type annotations for you using machine learning.

If you’re interested in the topics we’ve discussed above, you can also join our Slack community to continue the discussion!

The Prodo team is a group of full-stack developers who share a passion for simplicity and automation. Our mission is to make application development as fast and enjoyable as possible, and we believe that simple, declarative programming has a huge part to play in making this happen.

Combining React, Firebase and TypeScript with zero boilerplate.

Onurbon — Thu, 17 Oct 2019 22:57:40 +0000

We’ve spent the last couple of years building a variety of apps with React, Redux, TypeScript and Firebase. We love each of those technologies, but combining everything together in a nice way proved very difficult, and we continue to hear other teams struggling with similar issues. This post summarises our take on the core problems and provides some hints on the solutions that we’re now building.

The problem: mixing apples with oranges

Building full-stack applications with JavaScript in 2019 often requires integrating at least 3 or 4 pieces:

a framework to manage your visual components, e.g. React;
a framework to manage your application’s state, e.g. Redux;
a backend solution for your data and authentication, e.g. Firebase; and
if you like catching bugs at compile time, a type-system like TypeScript

A few solutions have been proposed to manage most of the above combination, such as the react-redux-firebase library on GitHub. But after 700+ commits from 80+ contributors (and even the much welcomed introduction of React Hooks), this library has not yet managed to provide a truly simple and intuitive developer experience, and we don’t think it can.

The core of the problem, in our opinion, is that a React/Redux/Firebase stack will always end up mixing very different patterns and computational paradigms for manipulating data:

🍏 React is processing data with synchronous functions , which are typically evaluated multiple times as the data is loaded and modified,
🍊Redux doesn’t let you just call functions, but instead forces you to dispatch actions which modify data using reducers that are typically evaluated a single time.
🍏 Because redux itself doesn’t have built-in support for asynchronous effects, you’ll probably introduce the concept of thunks (with redux-thunks) or sagas (with redux-sagas)
🍊Or you might have replaced redux by an alternative, thus introducing yet more concepts such as observables (e.g. MobX) or streams (e.g. Rx)
🍏 The interaction with Firebase relies on asynchronous functions , and the real-time data from Firestore is updated multiple times using subscriptions
🍊React Hooks may then be used to try and simplify a lot of the above, but they rely on yet another paradigm. Hooks are intuitively a form of dependency injection , and they typically handle the asynchronous nature of side effects using callback functions.

This is a huge technical mess, and is a very typical example of “framework fatigue”, something that is only getting worse in the JavaScript world. It is not an intuitive way to build applications, and forces beginners to deal with a steep learning curve. And it’s also a real-world problem for experts; writing code takes longer because of the boilerplate, reviewing code takes longer because of the general awkwardness and inconsistency, and writing tests is very cumbersome — meaning that you probably won’t write that many. And on top of all that, getting useful feedback from TypeScript is hopeless because most of the data coming from Firestore won’t be typed.

The solution: rethinking state management

We believe the problem of inconsistent patterns and paradigms can only be tackled by changing the layer that ties every thing together: the state management layer. A lot of simplicity can be achieved by reinventing state management with the right priorities in mind. In particular, we think that a good solution should:

Provide (most of) the same benefits as Redux, without the boilerplate and unnecessary abstractions (we’ll typically rely on proxies and/or transpilation to achieve this).
Drastically simplify the computational model to keep it in line with React (based on synchronous functions, evaluated multiple times).
Allow users to integrate backend technologies like Firebase by adding a “plugin” (in contrast to Redux’s middleware system, which is very low-level).
Enable maximal TypeScript inference by design (meaning that you define your schema once, and then TypeScript infers all your types, without requiring manual annotations).

Replacing Redux is quite an ambitious task — we’re talking about a library with 50k+ stars on GitHub, and more than 3M weekly downloads on npm. And we’re also not the first developers interested in replacing Redux (we found about ~100 related libraries on GitHub). But we haven’t found any attempt that followed the same priorities.

You might also have encountered dozens of “Redux is dead” blog posts on Medium in the last few months, often making the argument that GraphQL and/or React Hooks can help you get rid of Redux. But we found no real evidence of this outside of toy examples of apps. Hooks only provide a more convenient syntax to deal with React state or React context, but they’ve not drastically changed state management. Neither Hooks nor GraphQL have truly replaced Redux — they only let you reduce the amount of Redux needed in your application. That’s why we believe that state management remains a problem worth digging into.

Show me some code!

DISCLAIMER: We’re still experimenting with different options and invite you to check our repo to see what our framework looks like today. But we would also love your feedback (on Slack or in the comments below this article) on the syntax and architecture that we’re envisioning for the long term, which is outlined below.

Step 1: Define your data models

Prodo will give you a function dataModel parameterised by a type definition and a list of plugins. You’ll then be able to export variables such as state (the redux-state of your app), auth (the authentication data, automatically pulled from Firebase) and db (automatically synced with Firestore) which can be used directly in your action definitions. You’ll also be able to export a hook called useData to use (and watch changes in) the data in your React components.

Note in the above that we’re not exporting any type definition, because we won’t need any in the other files. That’s because we’ll be able to infer everything from the types of db, state, auth and useData.

Step 2: Define your actions

Prodo actions will be defined as plain old JavaScript functions and those function will be able to use mutation operations to modify data in your state and your database, as if they consisted of in-memory JSON objects. But this is obviously an abstraction.

Under the hood, we’ll use immer.js to implement copy-on-write semantics and keep track of data changes in a non-destructive way (thus making time travel debugging possible). We’ll also rely on dynamic binding to map state and db to the current execution context of each action. Intuitively, this means that an expression such as state.roomId will in fact evaluate to window.currentProdoContext.state.foo. This global variable currentProdoContext will then need to be to swapped when different actions start and terminate, by we’ll be able to do this in a reliable way as long as long as actions remain synchronous.

Note however that keeping actions syncrhonous doesn’t prevent us from using asynchronous effects, although this will also require special care. In particular, if the newId function in the above snippet was fetching some remote data, it would first need to throw an error saying “I’m not ready yet!”, and the action will need to be restarted from the top when the data does come in.

Those are only some of the technical details that will need to be addressed, but this was hopefully enough to give you an idea of how we want to bring the computational model closer to React’s model, using only synchronous functions, and allowing to re-evaluate these functions multiple times until all the data is ready and the computed patched can be applied.

Step 3: Using your data and actions from React

After defining our data models and our actions, we will then use them directly in React with the (typed) hooks that we have exported:

Here is what a Message component would look like:

Here is what a RoomSelector component (with a controlled input) would look like:

Here is what a PostMessage component would look like:

Finally, here is what our chat application will look like at the end, using a query function from Prodo’s plugin to pull and watch collections from Firestore:

A fair amount of non-trivial heuristics will be needed to ensure that the above components are re-rendered (efficiently) when the data is updated, but the experiments we’ve conducted so far suggest that we should be able to match Redux’s and MobX’s performances. You may also note that the above example — unlike most frameworks — are not requiring you to wrap every single component inside a “connect” functions. This is again something we’ve been able to achieve in our experiments (by dynamically redefining React’s createElement function to auto-connect all the relevant components), but the performance implications there will also require proper testing. And these are only some examples of the exciting challenges which we’re tackling now to achieve a truly simple, boilerplate-free experience for our users.

What now?

If you’ve liked what you’ve read so far, or just want to see where this is going, please consider starring our repository on GitHub, to let us know that you care. You can also stay up-to-date with upcoming features, and more importantly, join the discussion by joining our Slack Community.

If you want to jump right in, you can try Prodo today — our docs are online at https://docs.prodo.dev and you can quickly build your own example by following the tutorial here.