Как организовать общее состояние в react-приложениях без использования библиотек (и зачем нужен mobx)

1. состояние прибито к виду — стор должен знать о том, какую вложенность объектов требуют виды, чтобы именно с этой вложенностью объекты и хранились

В статье описан как раз противоположеный подход — мы храним данные в сторе моделируя как сущности и связи между ними (например юзер может создавать (изменять, удалять) папки, у них проекты, у проектах задачи и у задачах подзадачи. И соотвественно структура стора будет прямо соответствовать этим сущностям и связям — у объекта User будет храниться массив папок, у каждой папки массив проектов, у каждого проекта массив задач и у каждой задачи массив подзадач. В итоге нигде в структуре стора нет завязки на вид. А структура видов может быть совершенно разная — можно отображение проектов сделать на одной странице с папками (где список папок будет в сайдпанели) можно разнести по разным страницам. Можно как угодно структурировать и моделировать отображение — на структуру состояния это никак не повлияет.

2. избыточность и дублирование данных — при хоть сколько-нибудь сложных связях между объектами у вас один и тот же объект будет вложен в много разных других объектов. своевременно все это обновлять и следить за корректностью очень быстро становится сильно сложнее, чем денормализовывать данные на выходе стора.

Вот тут я вас не понимаю — объекты в сторе связываются по ссылке — соотвественно если проект отрендерил список задач (<div>{project.tasks.map(task=><Task task={task}/>}</div>) а компонент задачи отрендерил список подзадач точно так же передав подзадачу (<div>{this.props.task.subtasks.map(subtask=><Subtask subtask={subtask}/>}</div>) то изменение задачи в компоненте <Task/> (this.props.task.text = newText) и изменение задачи в компоненте <Subtask/> через ссылку на родительский объект (this.props.subtask.task.text = newText) это изменение одного и того же объекта и соотвественно никакого дублирования и неконсистентности не будет

В вашем примере

get folder() {
        return this.store.folders[ this.folder_id]
    }

если вы предлагаете просто вынести болерплейт аналогично такому

class Comment {
 get folderName {
 return AppState.folders[AppState.projects[AppState.tasks[this.taskId].projectId].folderId].name
}

в стор то суть проблемы не изменится — каждый раз при изменении компонентов нужно добавлять всякие хелперы в стор, более того теперь стор через эти хелперы будет знать о том какие данные нужны для вьюх и у нас model превращается в view-model.
А если же вы предлагаете создавать сторы и ссылаться друг на друга через геттеры внутри которых будет спрятано получение получения объектов по айдишнику, например

class Comment {
  get task(){
   return AppState.tasks[this.task_id]
 }
}
class Task {
   get project(){
     return AppState.projects[this.project_id]
  }
}
 class Project {
    get folder(){
       return AppState.folders[this.folder_id]
    }
 }

тогда да, благодаря геттерам у нас мы избавимся от болерплейта во вьюхах и сверху будет выглядеть как будто это обращение через ссылки

<div>{comment.task.project.folder.name}</div>

Но надо еще не забыть про прямые связи чтобы мы могли удобно рендерить списки (<div>{project.tasks.map(task=><Task task={task}/>}</div>) а не заниматься маппингом айдишников на объекты вручную

class Task {
   get comments(){
     return this.comments.map(commentId => AppState.comments[commentId])
  }
}
 class Project {
    get tasks(){
       return this.tasks.map(taskId => AppState.tasks[taskId])
    }
 }
 class Folder {
   get projects {
     return this.projects.map(projectId => AppState.comments[projectId])
   }
 }

И таким образом писать хелпер для каждой связи между сущностями чтобы скрыть слой получения объекта по айдишнику.
А если вдруг кроме нормализации еще требуется и иммутабельность то придется добавлять геттеры не только на связи но и на каждое поле вместе с сеттерами

class Task {
  ...
  get text(){
    return AppStore.tasks[this.id].text;
  }
  set text(newVal){
     return AppStore.tasks[this.id].text = newVal;
  }
}

В итоге, на мой взгляд, эта нормализация а потом попытка скрыть этот факт за сеттерами и геттерами это добавление ненужной абстракции на пустом месте. У нас уже есть возможность сохранить объект прямо на свойстве и обращаться к нему по ссылке. И это нативная возможность js без всяких слоев сверху. А мы добавили еще один слой абстракции только для того чтобы избавиться от ссылок и обращаться к объектам по айдишниками но при этом навешиваем сверху кучу геттеров все равно создав видимость обращение по ссылке.
Да, можно возразить, что для больших приложений чтобы не было тормозов все равно придется подключить mobx и там тоже будут геттеры и сеттеры но в этом случае они необходимы и не создают отдельный логически слой абстракции так как решают чисто техническую проблему уменьшения времени обновления компонентов. Более того с mobx это нормализация будет неэффективной потому что mobx трекает только факт обращения к хешу а не смотрит на айдишник и это значит что если комментарий в рендере обращается к стору <div>{comment.task.text}</div> где свойство ".task" это геттер (AppState.tasks[this.comment_id]) то любое изменение хеша (например добавление нового комментария) вызовет перерендер всех компонентов у которых происходит обращение к хешу AppState.tasks)

Чем хуже вариант:

class Task {
  _folder: Folder
  get folder() {
    return this._folder;
  }
}

Создавать по необходимости можно, нужность отслеживается стандартным сборщиком мусора и мы вообще о ней не думаем, пока он справляется. Проще ему или нет нас особо не интересует, пока не возникнет нужда в оптимизации, которая далеко не факт, что вообще возникнет.

Я не уверен, какова была цель автора, но статья мне показалось полезной в смысле демистификации решений управления состоянием в реакте.

Я просто вам подсказал, откуда боязнь библиотек и setState. И я не автор статьи.

Всего-то 5 лет понадобилось, и вот, костыли из первого ангуляра теперь называют "некостылями" в реакте.

А как вы предлагаете с помощью React.createContext управлять достаточно сложным состоянием (хотя бы массивом)?

Например, чтобы Context.Consumer перерендерил свои внутренние компоненты при добавлении элемента в массив, этот массив должен быть либо immutable (что подводит нас к Redux), либо реактивным (в терминах MobX).