Notes from Front-end London, February 2016

CSS Modules: Who, What, Where, When, Why?! - Christopher Pearce

locally scoped CSS
only accessible by direct reference
OOCSS and BEM feel a bit like avoiding the problem, not tackling it head-on
CSS Modules takes your styles and creates globally unique class names for the selectors
It's a fundamental change to the way we think about and write out styles
It's a guarantee that the code you're writing isn't impacted by the code outside it

import styles from 'buttons.css'

const Button = () => ()
    <button className={styles.button} />
);

There's the ability to provide defaults to be used
You can still use your usual post-optimisation workflow after CSS Modules have run
You can use Sass/LESS in front of CSS Modules

Often an issue with handing over designs to development
Need a way of including design in our agile development process
Breaking the wall
Get more people involved in the design process
- the more people creating ideas, the more problems you solve upfront
Run a design sprint
- a fast structured way of developing your ideas
- solve one design problem
- 5 stages (1 day each): unpack, sketch, decide, prototype, test

Prepare
- choose a problem
- gather your team, including:
  - a stakeholder
  - a manager
  - a developer
  - someone who knows the users
- clear your calendars
- schedule your user-testing in advance
- book a room, for the whole sprint
- gather supplies (post-its, pens, white-board, research data)
Unpack
- outline what to do
- share all the data and research
- make sure everyone is involved and heard
- work together to create user stories (customer and stakeholder)
  - try a flow diagram
Sketch
- break up the stories into sensible chunks
- crazy 8
  - fold a piece of paper into 8 and sketch an idea on each section
  - everyone votes on their favourite ideas
  - take the best to the next step
Decide
- what ideas to prototype to show the user
- what you want to get out of the user testing
- how you can measure if the prototype is a success
Prototype
- depends on the skills in your team: code / indesign / powerpoint even
- just make something the user can interact with (what would you expect to happen when you click here)
- use real copy in your prototype, not lorem ipsum
- ensure the script is right for the testing, work with the person running it
Test
- make sure everything is all set up and ready, double check
- you'll need a way to listen in, everyone involved in the previous steps should see it
- you want to get ways to improve your idea, and your product as a whole
- everyone records their opinions to compare

Plan them a bit ahead to be able to use the results
You might just need to fine tune it, you may need to break it down further or test it again
Even if they hated it, it's good to find out with only a day spent developing the prototype

JUST DO IT

Reductionism - any system can be understood by breaking it down into it's parts
Redux: Current State + Action = New State
- every action advances the state forward
reducer takes a state, applies an action to it, and returns a new state
In a nut shell
- A change in an element triggers an action
- This goes into the reducer with the existing state
- The reducer returns a new state
- The store takes this new state and updates the components
- Components re-render if they need to

Impressive live coding goes here...

Store
- takes a reducer argument
- has a state
- a function to dispatch actions state = reducer(state, action)
- a way to retrieve the state
- a way to subscribe to changes in the state
  - simplistically adding each listener to the list of listeners
Reducer
- takes a state and an action, and returns a new state
Actions
- have a type, value
- if (action.type === 'ADD') return [...state, action.value]
Have some kind of component that dispatches an action when its value changes

Take a look at SoundRedux
create reducers for each different part of your state
- use combineReducers
- each one returns the slice of the state it's interested in
State design is one of the big challenges