Недавно я начал изучать фреймворк Angular2, и меня поразил подход Redux/@ngrx к управлению состоянием. Изучение Angular2 с помощью @ngrx создало благотворный цикл, в котором концепции одного подкрепляют другие. Мне казалось, что я постигаю оба фреймворка гораздо легче, чем если бы изучал их по отдельности.
Но даже с этим эффектом множителя обучения я знал, что мне придется написать несколько приложений, прежде чем я смогу даже заявить, что знаком с angular2 и ngrx, не говоря уже о мастере!
Кто не писал (или не копировал :-)) образец Todo при изучении нового языка или фреймворка?! Спешка, которую вы испытываете, когда приложение обретает форму, великолепна, и вы не хотите, чтобы пример / учебник когда-либо заканчивался! Вы думаете про себя… Как мне растянуть опыт? Как сделать *моё* приложение Todo самым плохим приложением Todo во всемирной паутине?? И вы продолжаете копаться в образце, пытаясь изучить новые (намного лучше, чем старые!) лучшие практики, спускаясь в кроличью нору результатов поиска Google.
Через пару часов учебник показал бы вам, как реализовать достаточно функциональное приложение Todo, в котором вы действительно можете создавать задачи!
И отменить/повторить свои задачи…
И сохраните задачи в удаленной базе данных…
И реализовывать автономные возможности…
И синхронизируйте свои задачи с несколькими устройствами/браузерами…
И…
Что?! Это не так? Кто бы это сделал!
Учебники (и примеры приложений) написаны, чтобы выделить определенные концепции языка/фреймворка. Писателю пришлось бы написать книгу (или серию), чтобы охватить все доступные или желаемые функции. Учащемуся придется потратить месяцы на практику, чтобы понять каждый сценарий и пограничный случай. И в конечном счете, чем полнее учебник, тем сложнее его понять.
Эти проблемы, вероятно, являются причиной того, что руководства по приложениям Todo склоняются в одном из трех направлений:
1. Реализовать базовые задачи (без сохраненного состояния)
2. Реализовать отмену/повтор (с локальным состоянием) — [пример]
3. Реализовать удаленное состояние (без отмены/повтора) — [пример]
Конечно, эти две задачи (управление состоянием и отмена/возврат) должны быть «ортогональными» — мы должны иметь возможность объединить две возможности
в одно приложение без каких-либо проблем. Нет!! Мои попытки совместить эти две функции явно не увенчались успехом.
Итак, вернемся к основным принципам и изучим все остальные концепции, которые я пропустил!
