Wilson Page: The Component Approach

Wilson Page (@wilsonpage) was speaking at Smashing Conference about component based architecture, these are my notes from his talk.

With the componet approach we are breaking our pages into chunks.  Everything is a reusable component.

What is a component

Comines with other parts to form something bigger. For example the <video> element, has a public API - the interface, emmits events.

1. Markup
2. Styling
3. Behaviour

Definition

Don't need a framework.  Can do this as vanilla JS with a small wrapper.  Frameworks give a consistent codebase, interoperability, abstract repetition.  Writing your own can give control over how it works.

With the FT framework it was designed to be retro-fitted, should work alongside existing site.  Pass JSON data into the component and render it into the page.  Server side rendering was desired to support non-JS devices, faster time to content, support lower end devices without appyfying.

Client and server share definition, views rendered as strings as don't have a DOM.  Client enhances server generated HTML.

Encapsulation

Promotes reuse, there's no shared state.  Decoupled from application.  Lower barrier to entry, don't need to know the whole thing to work on one component.  Improves the sense of ownership as an application grows.  Can make changes to one without affecting others.

Move opinionated code out of the implementation into configurable items - dependency injection.

Each component is a mini-app.  Inject dependencies  - ignorance is bliss.

Communication

API and events.  API allows us to talk to the component, events allows the component to talk to us.  Components should never alter the application.

Events are great but know when to use them.  Describe what happens, not the interaction - let the component decide what the interaction is.  Event propagation allows us to listen to deeply nested components.

Good communication prevents circular dependencies.

Layout

Layout is expensive, it locks the DOM - layout thrashing.  FastDOM avoids this by batching layout operations in each animation frame, first writes then reads.  Async and non-blocking.  Layout boundaries can be used to limit the scope of a layout operation - gave a 300% improvement.  Improves animation frame rate.

Layout boundary has the following CSS:  width: 100%; height: 100px; overflow: hidden

Styling

Split up each component into an individual CSS file.

Maximise portability, minimise leakage:  purely discipline.

Like JS closures, we need to add some scope.  Use namespaced prefixes for CSS classes, looks a bit messy but prevents leakage in either direction.

Responsive

Components need to change their appearance, not just styling but also behaviours.  Same markup but different appearnce and behaviours.

Define layout states and give each a setup and teardown function.  Can use MQ to add CSS properties which can then be read back by JS - however, this is very slow.  Can add listeners to a window.matchMedia to trigger when an MQ is triggered.  Now JS is manageing the media queries so add a class hook via JS to control the appearance.

Conclude

• Tight scope promotes reuse
• Use configuration
• Public interface
• Use events to react to changes
• Make sure they aren't layout thrashing
• Smart CSS selectors
• Look to existing componets
• matchMedia is useful