But this all took place in a Drupal 7 world, and the question I would like to pose today is, what does such a model look like in Drupal 8?
The answer, I’m happy to say, is already in development. I call it “Decoupled Blocks,” and an initial proof of concept version of the code exists as a Drupal sandbox project and github repository today that you can install on your Drupal 8 site and try. I have been talking about this idea around the country for the last few months, first at San Francisco Drupal User’s Group (recording here), then Sand Camp, Florida Drupal Camp (recording here), and most recently in an Acquia webinar (recording here). The reception to the idea so far has been overwhelming, but getting more community buy in and architectural help will ensure it is built in a way that accommodates as many use cases as possible. So at its root, this post aims to be a request for help.
Two weeks ago, Acquia and Mediacurrent sponsored a joint sprint at Acquia headquarters to push this module forward for showcasing at DrupalCon New Orleans. We sprinted with members of both the Office of the CTO and the Acquia Lightning distribution. I was also privileged to get to speak directly with Dries about the progress we made and the roadmap leading us forward.
Aside from code cleanup and major improvements to our overall architecture, we also made exciting feature progress like:
Instance configuration for components can now be written into the info.yml file as form fields that will be converted to FAPI and available during block placement. These configuration values are then automatically passed through drupalSettings to the client for use by the component.
Components can add contextual requirements for display (currently only entities), and the context object is similarly passed to the client via drupalSettings automatically for use.
A separate DrupalVM repository for the project has been created so you can clone the repo, vagrant up, and jump into helping the development efforts immediately from your local machine.
Discovery began on abstracting out a Component API module, so the same components could also be used for other things like static page generation for rapid prototyping and living style guides.
I’m extremely interested in integration with the GraphQL module, which could allow us to throw away dozens of REST API endpoints and instead let the client request exactly the data they want on a component-by-component basis. This could offer us a valuable third way for components to access Drupal’s data, aside from RESTful API’s and drupalSettings.
I will be speaking about this module again at DrupalCon New Orleans, and also have a brainstorming BOF and Friday sprint scheduled. If you will not be in New Orleans and would like to help, please do reach out and let’s make Drupal deliver both the cutting edge user experiences and robust editorial tools we all know it can!