Telichkin's comments

I've found that most of the time dev teams use async workflow for code reviews. But it delays releases and leads to a lot of postponed context switches. In my experience, sync code reviews that have higher priority over other tasks is a much more productive workflow. With sync reviews we can deliver faster and improve the quality of the codebase

The "About" section of this art project:

We have tried to show the most important events in the history of space exploration: first spacecrafts, flights to other planets and landings on celestial bodies.

We believe that achievements in space belong to all mankind. We believe that space exploration is a significant step in the evolution of our civilization.

My current company is transforming into Agile right now, and I find this article is very good description of all these crazy stuff which happen in the company:

> Until today’s meeting, the friendly Agile consultant at my company has spent his time photoshopping the team leader’s face onto pictures of Yoda, and researching the motivational properties of various colours of magic marker. And he gets paid for it.

> doesn't shoehorn OOP into an FP approach to UI

Functional UI is still need some sort of imperative shell [1] to manage state. You can use OOP and Remold just for "reactive" behaviour, and implement all state transitions inside object in a functional way. For example:

    // Pure function
    const addProduct = (order, product) => ({
        total: order.total + product.price,
    });
    
    // Imperative state
    class Order extends Remold {
        state = {
            total: 0
        };        

        @act setState(newState) { this.state = newState; }

        addProduct(p) { this.setState(addProduct(this.state, p)); }
    }

> What are the advantages of this solution over features already in React (no need of Redux) such as context and the reduce hook?

From the React Documentation about Context feature [2]:

> Apply it sparingly because it makes component reuse more difficult.

With Remold you don't have any problems with component's reusability. You just attach pure component to an object and "connect" object's state into component's props:

    // Pure component
    const OrderWidget = ({ total }) => <div class="widget">{total}</div>;
    
    // Pure function
    const addProduct = (order, product) => ({
        total: order.total + product.price,
    });
    
    // Imperative state
    class Order extends Remold {
        state = {
            total: 0
        };        

        @act setState(newState) { this.state = newState; }

        addProduct(p) { this.setState(addProduct(this.state, p)); }
        
        @mold(OrderWidget) asWidget() { return { total: this.state.total }; }
    }

[1] https://www.destroyallsoftware.com/talks/boundaries

[2] https://reactjs.org/docs/context.html?no-cache=1#before-you-...

When I started a new React-project at my work, I asked myself: "Why do I need any external dependencies for state management such as Redux or MobX? What functionality from this dependencies do I need in the first place?".

I realised that I just want to have many views connected to one dataset, and I want to re-render all connected views when dataset was changed. This is a simple pub-sub pattern which everyone can implement himself. So, I implemented it myself in just 65 lines of code. I use this solution in production for 6 months and don't see any drawbacks.

What are the advantages of Redux or MobX over this solution?

Totally agree with you. React is just an API which enhances vanilla JavaScript. In React it's possible to use all prior knowledge and practices from other languages, eg functions/objects composition, and decoration.

Vue is different. With it, you can't confidently use your previous programming experience.

You can do what you want just in 17 lines of pure JavaScript. This is an example:

  const

  create_store = ({state, actions}) => {
    const

    after_update_do = [],

    subscribe = fn => after_update_do.push(fn),

    notify = () => after_update_do.forEach(fn => fn(state)),

    create_action = action => (...args) => {
      state = action(state, ...args);
      notify()
    };

    return Object.entries(actions).reduce((bound_actions, [action_name, action]) => 
      Object.assign({}, bound_actions, {[action_name]: create_action(action)}), 
      {subscribe})
  },

  counter = create_store({
    state: 0,
    actions: {
      increase: state => state + 1,
      
      decrease: state => state - 1,

      multiply_add: (state, a, b) => state * a + b,
    },
  });

  counter.subscribe(state => console.log('First reactive component was updated with: ' + state));
  counter.subscribe(state => console.log('Second reactive component was updated with: ' + state));

Now you can call all actions directly from the counter and update all components in reactive manner.

  counter.increase();
  // First reactive component was updated with: 1
  // Second reactive component was updated with: 1

  counter.multiply_add(2, 3)
  // First reactive component was updated with: 5
  // Second reactive component was updated with: 5

Sorry, but I can't understand why should I use this app instead of saving notes in a source code?

Have you tried a pair programming? I realized that this practice much more effective than code review. Pair programming encourages learning inside a team, interactions and code quality. It also reduces time to market.

I'm learning Erlang right now and find that every OTP behavior has main parts in its API: client, server, possible inputs and possible outputs. But a one-dimensional structure of standard documentation (from top to bottom) can't present all these parts in one place which leads to loss of a context and longer learn-curve. That's why I create this cheat sheet to present OTP behaviors in one place using opportunities of a two-dimensional structure.