abhiaiyer91

Redux Selector Pattern

Imagine we have a reducer to control a list of items:

function listOfItems(state: Array<Object> = [], action: Object = {}): Array<Object> {
  switch(action.type) {
    case 'SHOW_ALL_ITEMS':
      return action.data.items
    default:

ktilcu

The initial function seemed straightforward and very close to functional programming but there was a bit of buried complexity.

function generate(seedWords) {
  const filteredWords = filterInputs(seedWords);
  const initialHash = R.head(filteredWords) || 'thunder';
  const hashWithRandom = appendRandom(initialHash);
  return generateHelper(hashWithRandom, R.tail(filteredWords));
}

ktilcu

During a recent discussion Nathan made 2 excellent points about partials:

1. partials can be unneeded.
2. partials can be opaque.

I would like to support those and add a bit of advice:

3. Avoid partials!

Un-needed _.partial

ktilcu

I was reading this article about why A/A is better than Promises and saw a few code examples stood out to me as being unfair. I am not saying A/A is not better, I just think we need to be a lot more explicit about why it's better. Read below and I will go through each section in the article.

Overall, I think the main benefit of A/A is readability for people who are not familiar with Promises. The problem is that in order to understand A/A at a useful depth, you have to understand promises. In my mind, we are just covering one problem with another and making YAA (yet another abstraction) that people have to understand in order to figure out async programming.

I think a post talking about how to do promises well would be much more useful than one that shows that new language features are better than bad code.