AN OVERVIEW OF FRONT END COMPONENT INTEGRATION METHODS IN DRUPAL Brian Perry DrupalCamp Asheville – July 11, 2020
http://bit.ly/component-int
Slide 2
BRIAN PERRY • Lead Front End Dev at Bounteous • Rocking the Chicago ‘burbs • Lover of all things components… …and Nintendo d.o: brianperry twitter: bricomedy github: backlineint nintendo: wabrian brianperryinteractive.com
2
Slide 3
3
Slide 4
YIKES!
2020, huh?
Slide 5
COMPONENTS!
Slide 6
COMPONENT BASED DEVELOPMENT What is it?
• Creating modular and re-usable elements • Building a design system, not a series of pages • Can use a pattern library for documentation and prototyping •
Tools like Pattern Lab and Storybook
6
Slide 7
COMPONENT BASED THEMING Why Take a component-based approach? •
•
Efficient re-use •
Write once, use everywhere.
•
Within a single project and even across projects (beyond Drupal even)
•
Decoupling front and back end development •
•
Theming doesn’t have to come last
Living Style Guide / Pattern Library •
Simplifies coordination between designers and developers / developers and developers.
•
Rapid prototyping
•
Design system source of truth
Well isolated chunks of code
7
Slide 8
OUR EXAMPLE COMPONENT
Slide 9
9
Slide 10
{{ title }} {{ platform }}
{{ year }}
{{ image }}
{{ body }}
{{ link }}
10
Slide 11
11
Slide 12
12
Slide 13
GRID LAYOUT
13
Slide 14
14
Slide 15
COMPONENTS IN DRUPAL
Slide 16
WHERE DO MY COMPONENTS LIVE? For the sake of this talk…
Standard Drupal Components
Integrated Drupal Components
•
Live in the default template directory
•
•
May not require any additional effort to get data to display
Live somewhere other than the default templates directory
•
Require some additional effort to get data to display
•
For this talk, I don’t really care how your integrated components get into your theme. •
Could live in your theme
•
Could be external dependency 16
Slide 17
STANDARD DRUPAL COMPONENTS Building components that live in the traditional templates directory
Slide 18
STANDARD DRUPAL COMPONENTS May be right for your team or project. No shame necessary. • Build with Drupal (and only Drupal) in mind. • Take advantage of things that can be re-used in Drupal • Display modes • Blocks • Paragraphs • Layouts • Lose out on rapid prototyping advantages.
18
INTEGRATED DRUPAL COMPONENTS Building components that live outside of the traditional templates directory
Slide 25
COMPONENT LIBRARY / PATTERN LAB
25
Slide 26
COMPONENTS MODULE Creates Twig namespaces to access templates in non-standard locations
26
Slide 27
INTEGRATION APPROACHES Primarily fall into two categories
Mapping Data In Code •
Includes:
Mapping Data In Admin UI •
Includes:
•
Mapping in Twig templates
•
UI Patterns
•
Preprocessing
•
Layouts
•
Themes and starter kits
•
More likely to get out of sync with Drupal UI
•
More likely to break things like caching, Drupal functionality, etc.
•
Less likely to disrupt Drupal functionality
•
Potentially not as flexible
27
MAPPING IN TWIG PRESENTER TEMPLATE Drupal template references template in component library
30
Slide 31
DATA MAPPING IN PREPROCESS Map in preprocess…
32
Slide 32
DATA MAPPING IN PREPROCESS …and use simpler include in Twig presenter template
33
Slide 33
HELPER MODULES Simplify Twig Mapping
Twig Field Value •
Get Partial data from field render arrays •
field_label
•
field_value
•
field_raw
•
field_target_entity
•
Map just the data you want
•
May require additional caching considerations…
Twig Tweak •
Helpful twig functions and filters •
Render views, blocks, regions, fields, entities and so on.
•
Render image with specific image style
•
Extract tokens from context
34
Slide 34
STARTER KITS AND THEMES • Simplify set up and provide default tooling • Some provide default components and helper functions • Various levels of opinionated • Examples: • Emulsify • Gesso • Shila • Particle
35
Slide 35
EMULSIFY DESIGN SYSTEM EXAMPLE • Same presenter templates • Different component location • Different component library tool
36
Slide 36
37
Slide 37
38
Slide 38
MAPPING DATA IN THE ADMIN UI
Slide 39
UI PATTERNS MODULE Define and manage components in a way that Drupal understands
• Define UI Patterns as Drupal Plugins • Use defined patterns with component friendly modules • Views, field groups, layout builder, display suite, paragraphs (requires field layout or display suite)
• Configure data mappings in the UI • Optional Pattern Library page exposed in Drupal • Also allows Drupal to: • Preprocess patterns • Render patterns programmatically 40
Slide 40
{{ title }} {{ platform }}
{{ image }}
{{ year }}
Pattern: container
{{ body }}
{{ link }}
41
Slide 41
42
Slide 42
43
Slide 43
44
Slide 44
UI PATTERNS VIEWS
45
Slide 45
46
Slide 46
LAYOUTS {{ region: title }} {{ region: platform }}
{{ region: image }}
{{ region: year }}
Layout: container
{{ region: body }}
{{ region: link }}
47
Slide 47
LAYOUTS AND LAYOUT BUILDER
48
Slide 48
LAYOUTS AND LAYOUT BUILDER
49
Slide 49
LAYOUTS AND LAYOUT BUILDER Add ‘container’ section for teaser layout
50
Slide 50
LAYOUTS AND LAYOUT BUILDER Challenges: • For full layout builder functionality, need to retain container and region attributes • Need to be able to addClass and attributes functions in Pattern Library • Some components might not be practical for visual field mapping • Layout Builder UI introduces additional markup that may conflict with your component
51
Slide 51
COMPONENT DEFINITION APPROACHES
Manual Definition •
Define component in code so that Drupal becomes aware of it.
•
Likely requires some amount of duplication between Drupal and component library
Automatic Discovery •
Drupal module automatically discovers components from component library and makes them available to Drupal.
•
Emerging/experimental concept.
•
Expects a particular convention and thus won’t work with all component libraries.
52
Slide 52
AUTOMATIC DISCOVERY
Slide 53
UI PATTERNS PATTERN LAB Automatically create UI Patterns from your pattern library… really. • End result same as previous UI Patterns Example • No redundant ui_patterns.yml file necessary • Some limitations • Requires yml or json file with pattern data • Requires specific approach to nested components.
54
Slide 54
LAYOUTS FROM PATTERN LAB Automatically create Drupal Layouts from your pattern library… really. • No explicitly defined layout necessary • Use with Layout Builder • Can select default field wrappers or only content (similar to UI Patterns) • Early - many limitations • Need to work around Pattern Lab 3 not working with html.twig extension • Open issues with Layout Builder drag and drop. 55
Slide 55
PATTERNKIT Combines aspects of manual definition and automatic discovery • Requires creating schema definition file (which has potential applications outside of Drupal) • Automatically derives blocks from pattern library components • Supports a specific set of field types • Token support in D7 but not yet D8
56
Slide 56
PATTERNKIT PATTERN DISCOVERY
57
Slide 57
58
Slide 58
59
Slide 59
PRE-PACKAGED COMPONENT SOLUTIONS
Slide 60
BOLT DESIGN SYSTEM Ready to use web-components
• Full design system • Selectively require components.
61
Slide 61
COMPONY Component distribution system
• Combines a theme, Gulp workflow and components. • Download existing components or create your own • Not Composer / NPM driven
62
Slide 62
SINGLE FILE COMPONENTS Drupal components with Vue style syntax • Use like any template • Automatically generates library definitions • Derive Blocks and Layouts with Annotations • Provides component library • Doesn’t really solve integration problem • Does help with distribution and re-use. 63
Slide 63
COMPONENT WORKFLOW Present and Future
Slide 64
CURRENT APPROACH(ES) Leveraging a mix of approaches • Integrated components in a custom theme • Majority of twig/sass/js inside Pattern Library instance. • Defining component mapping in Drupal UI for lightweight components • Preprocess for components with heavy logic • Created preprocess helper abstract class – hope to open source in future • Project specific helper functions • Build components compatible with Layout Builder • Custom block types with limited use of Paragraphs • Limited mapping in twig templates 65
Slide 65
DREAM WORKFLOW Basically React (or insert the name of your favorite JS framework here) • Build fully packaged distributable components • Easily install them • npm install cool-component / composer require drupal/cool-component • Import them in code • import ‘CoolComponent’ from ‘cool-component’; / {% include ‘@components/cool-component.twig’ %} • Use them as I see fit • <CoolComponent />
66
Slide 66
HOW DO WE GET THERE? We seem to have a lot of the pieces • Make it easier to package, distribute and use individual components • Track evolution of Web Components • Improve UI based component configuration process in Drupal • With specific focus on Layout Builder. • Evolve approaches allowing Drupal to automatically discover components • Keep building amazing looking component based sites using Drupal
67
Slide 67
Thanks to the many Drupal component ecosystem contributors!
Slide 68
FEEDBACK APPRECIATED
69
Slide 69
Q&A Brian Perry Lead Front End Developer Email: brian.perry@bounteous.com