DrupalCon Seattle 2019: Design a decoupled application
The world of decoupled Drupal is reaching a state where arguing about whether you want to decouple or not becomes less and less something you discuss. Instead people start to talk about common problems, best practises.
The Drupal admin UI team has build a user experience focused decoupled application to create and manage the content of Drupal, while trying to apply best practises and pushing the Drupalisms away as much as possible.
First we will focus on why we went with a fully decoupled approach, and why other projects would profit from a less tight integration into Drupal as well.
We will discuss common approaches to routing, fetching data, managing state with autosave as well as some level of extensibility.
# Summary
* Full decoupled vs. progressive decoupled
* Client vs. serverside routing
* Extension mechanisms
* Drupal's idea of extensibility
* Advanced UI patterns: UI saving, undo/redo
* How do onboard existing Drupal themers into the new React world?
* To which degree is it okay to create custom endpoints to serve data?
The Drupal admin UI team has build a user experience focused decoupled application to create and manage the content of Drupal, while trying to apply best practises and pushing the Drupalisms away as much as possible.
First we will focus on why we went with a fully decoupled approach, and why other projects would profit from a less tight integration into Drupal as well.
We will discuss common approaches to routing, fetching data, managing state with autosave as well as some level of extensibility.
# Summary
* Full decoupled vs. progressive decoupled
* Client vs. serverside routing
* Extension mechanisms
* Drupal's idea of extensibility
* Advanced UI patterns: UI saving, undo/redo
* How do onboard existing Drupal themers into the new React world?
* To which degree is it okay to create custom endpoints to serve data?