DEV Community: enguerran 🐐💨

Vuex State and Getters (2)

enguerran 🐐💨 — Mon, 27 Apr 2020 16:30:00 +0000

To be honest, I wasn't sure what I was writing when I wrote the previous article about Vuex State and Getters. And the more I use Vuex, the more I question this "everything in Getters" proposition. In the end, writing this article allowed me to review the situation.

I know why something did not smell right to me.

The case of the Vuejs components

Several data are accesible within a component, they can come from props, be defined in data or be calcultated in computed.

When we use them in the teplate, we don't ask ourselves the question of their origins, they are all accessible through the this interface.

Vue.component("ButtonCounter", {
  props: {
    name: {
      type: String,
      default: () => "John Doe"
    }
  },
  data: function() {
    return {
      count: 0
    };
  },
  computed: {
    times: function() {
      return this.count === 1 ? "time" : "times";
    }
  },
  template: `
  <button v-on:click="count++">
    Hi {{name}}, you clicked me {{ count }} {{times}}.
  </button>`
});

Vuejs props, data and computed properties

(Codesandbox Vuejs demo)

The case of React components

There are two interfaces: this.state and this.props. The first handles internal data of the component. The second handles external data of the component whether it comes from the calling component or the state manager.

class ButtonCounter extends React.Component {
  constructor(props) {
    super(props);
    this.state = { count: 0 };
  }

  render() {
    const { count } = this.state;
    const { username } = this.props;
    const times = count === 1 ? "time" : "times";
    return (
      <button
        onClick={() => {
          this.setState({ count: count + 1 });
        }}
      >
        Hi {username}, you clicked me {count} {times}.
      </button>
    );
  }
}

React props and state

(Codesandbox Reactjs demo)

The case of Vuex

Whether the data is directly provided by the state of the store, or the data is derived, we don't have the same interface: this.state vs this.getters. And the consumer of the data has to be aware of the internal organization of the store, which is a bit disturbing.

const initialState = {
  todos: [
    { id: 1, text: 'Learn about State', done: true },
    { id: 2, text: 'Learn about Getters', done: false }
  ]
};

function doneTodos(state) {
  return state.todos.filter(todo => todo.done)
}

const store = new Vuex.Store({
  state: initialState,
  getters: {
    doneTodos: doneTodos
  }
})

Vuex state and getters

To access the todos, components can add a computed properties:

Vue.component("TodoList", {
  computed: {
    todos: function() {
      return this.$store.state.todos
    },
    doneTodos: function() {
      return this.$store.getters.doneTodos
    }
  },
  template: `
  <ul>
    <li v-for="todo in todos" :key="todo.text">
      {{ todo.text }}
    </li>
  </ul>`
});

Usage with Vuejs

The case of Redux

Getters are referred to as Selectors and handle providing derived data. In a redux vanilla framework, we will implement a function well-named mapStateToProps (transforming a data of the global state into a component's props property).

const initialState = {
  todos: [
    { id: 1, text: 'Learn about State', done: true },
    { id: 2, text: 'Learn about Selectors', done: false }
  ]
};

function doneTodos(state) {
  return state.todos.filter(todo => todo.done)
}

const store = createStore(function(state, action) {
  if (typeof state === 'undefined') {
    return initialState
  }

  return state;
});

Redux state and selectors

This creates container components (connected to the state manager).

class TodoList extends React.Component {
  constructor(props) {
    super(props);
    this.state = { count: 0 };
  }

  render() {
    const { todos, doneTodos } = this.pros;
    return (
      <ul>
        {todos.map(todo => (
          <li>{todo.text}</li>
        ))}
      </ul>
    );
  }
}

const mapStateToProps = state => {
  return {
    todos: state.todos,
    doneTodos: doneTodos(state)
  }
};

const TodoListContainer = connect(mapStateToProps)(TodoList)

Usage with Reactjs

Conclusion

React and Redux don't do something special for computed properties or getters, they are only functions that take a raw data as a parameter and return a computed data.

Vuejs and Vuex treat computed properties and getters in a special way that force developers to adapt their code to the framework (in order to be reactive):

The Vuejs component that consumes a Vuex data must know how the state is organised;
Developers need to know the correct interface to access the state data regarding if they are raw or computed data.

Vuex state and getters

enguerran 🐐💨 — Tue, 10 Mar 2020 00:00:00 +0000

(edit) I have evolved my thinking on the subject, which I have expressed in a new article: https://dev.to/enguerran/vuex-state-and-getters-2-2l34

With vuex is there a reason why it's better to access state directly than via a getter if the getter is just returning the state?

Let us first take care to illustrate this issue:

the store

const store = new Vuex.Store({
  state: {
    messages: [
      { from: "Bob", to: "Alice", content: "Hello, Alice!" },
      { from: "Alice", to: "Bob", content: "Hi, Bob!" },
      {
        from: "Bob",
        to: "Alice",
        content:
          `What is the difference between accessing the state directly
          rathen than using a getter?`
      },
      {
        from: "Alice",
        to: "Bob",
        content: `This is your last chance.
          After this, there is no turning back.
          You take the blue pill—the story ends,
          you wake up in your bed and believe whatever you want to believe.
          You take the red pill—you stay in Wonderland,
          and I show you how deep the rabbit hole goes.
          Remember: all I'm offering is the truth. Nothing more.`
      }
    ]
  },
  getters: {
    messages: state => state.messages
  }
});

Vuex store

two very different components

In both components, messages are the responsibility of a Vuex store.

RedPill: direct access to the state

export default {
  name: "HelloWorld",
  computed: {
    messages() {
      return this.$store.state.messages;
    }
  }
};

RedPill component

In the component <RedPill />, we access the state directly via the store object which is injected to all root child components.

The component retrieves the list of messages and can display their content:

<template>
  <div class="hello">
    <h1>Dependant of the state organization</h1>
    <ul v-for="(message, index) in messages" :key="index">
      <li>{{message.from}} to {{message.to}}: {{message.content}}</li>
    </ul>
  </div>
</template>

Vue template to display messages

BluePill: using a getter

export default {
  name: "HelloWorld",
  computed: {
    messages() {
      return this.$store.getters.messages;
    }
  }
};

BluePill component

In the other component <BluePill />, we access the state via a getter which is not complex since it returns directly the object: const messages = state => state.messages.

From a component and the application point of view, there is no difference.

how deep does the rabbit hole go?

The RedPill is dependant of the internal state organization. Every time the state is reorganized, the RedPill should be updated. The RedPill has a big responsibility: to know where it can find the list of messages.

On the other hand, the BluePill is independent of the internal organization of the state because it asks the store, whenever it needs it, to return the list of messages. The BluePill does not have the responsibility to know where it can find the list of messages.

Let's say that the Vuex store is redesigned to allow organization in modules.

const store = new Vuex.Store({
  state: {
    messages: [
      { from: "Bob", to: "Alice", content: "Hello, Alice!" },
      { from: "Alice", to: "Bob", content: "Hi, Bob!" },
      {
        from: "Bob",
        to: "Alice",
        content:
          `What is the difference between accessing the state directly
          rathen than using a getter?`
      },
      {
        from: "Alice",
        to: "Bob",
        content: `This is your last chance.
          After this, there is no turning back.
          You take the blue pill—the story ends,
          you wake up in your bed and believe whatever you want to believe.
          You take the red pill—you stay in Wonderland,
          and I show you how deep the rabbit hole goes.
          Remember: all I'm offering is the truth. Nothing more.`
      }
    ]
  },
  getters: {
    messages: state => state.messages
  }
});

Vuex store before refactoring

Now we want to use Vuex modules:

const store = new Vuex.Store({
  modules: {
    messages: {
      state: {
        messages: [
          { from: "Bob", to: "Alice", content: "Hello, Alice!" },
          { from: "Alice", to: "Bob", content: "Hi, Bob!" },
          {
            from: "Bob",
            to: "Alice",
            content: `What is the difference between accessing the state directly
              rathen than using a getter?`
          },
          {
            from: "Alice",
            to: "Bob",
            content: `This is your last chance.
              After this, there is no turning back.
              You take the blue pill—the story ends,
              you wake up in your bed and believe whatever you want to believe.
              You take the red pill—you stay in Wonderland,
              and I show you how deep the rabbit hole goes.
              Remember: all I'm offering is the truth. Nothing more.`
          }
        ]
      },
      getters: {
        messages: state => state.messages
      }
    }
  }
});

Vuex store with modules

I have to update the RedPill computed data:

export default {
  name: "HelloWorld",
  computed: {
    messages() {
      return this.$store.state.messages.messages;
    }
  }
};

Tightly coupled to the store

But not the BluePill's one.

export default {
  name: "HelloWorld",
  computed: {
    messages() {
      return this.$store.getters.messages;
    }
  }
};

Weakly coupled to the store

And that is the same about adding a new feature.

Let's say messages are updated to have a boolean that expresses the need to be displayed or not: draft: true.

You just need to update the getter and everything is right:

getters: {
  messages: state => state.messages.filter(message => !message.draft)
}

Shotgun surgery avoidance

That is an introduction to coupling in software development.

What Is it Like to Be a Developer?

enguerran 🐐💨 — Thu, 09 Aug 2018 13:46:34 +0000

Questions about what to do, what to learn or what to use from beginners or advanced developers are often answered with the subjectivity of a singular person. That person could be a doctor in Computer Science studying Ditributed Neural Networks or a self-taught JavaScript developer. That is not hard to understand their answers will be very different not helping the beginner asking for advices.

The title of this post is directly inspired by "What is it like to be a bat?": it is a paper by American philosopher Thomas Nagel, first published in The Philosophical Review in October 1974.

Noone's experience could be compared to another one's experience. That is the fundamental origin of the impostor syndrom. Each developer goes his own way towards what he tends to become, and if some paths are identical, we cannot conclude to similar experiences if we take into account qualia.

Qualia are defined to be individual instances of subjective, conscious experience.

That means that if you get an advice, you have to transpose that advice into your own inherent experience before building some kind of experience about it.

Examples of Advice

Work Hard

For me, work hard means read and practice a lot. I need to confront what I understand from a theory with a concrete example that I can manipulate.

That will not be necessarly the same for another person.

Understand What You Are Doing

How do you know my understanding is the same your understanding? I could paraphrase and try to explain what I understood. But there will never be an assurance that I understood what you try to explain to me.

On the other hand, some genius people are capable of doing things they do not understand theorically speaking. And that is not necessarily a problem.

We can sum this up by saying that you may try to be able to reproduce what you did in some other similar contexts, and that might be enough to validate that advice.

Avoid Dogmas

I need to understand what I am doing, this brings me confidence. Otherwise, I quickly become stressed and question my whole life and all my choices. That's why I hunt dogmas by trying to explain everything.

But I can beleive that is not the case for everyone. That someone else can live a long and happy life believing something without ever having to confront reason, experience or theory. And it's not necessarily a problem to be able to do something (it could be a problem if you have to teach someone).

What Is it Like to Be a Developer?

To be a good developer, you should seek to feel positive things when you do what it is for you to be a developer. That is, in the end, the only thing that matters.

And, please, forget comparisons, competitions. Help your entourage by listening to their questions, after all, it is the rubber duck technique that works so often in our profession.

Hi, I'm enguerran 🐐💨

enguerran 🐐💨 — Wed, 01 Mar 2017 07:52:57 +0000