Principle of Least Power

Axioms of Web Architecture

by

Tim Berners-Lee

Given a choice of solutions, pick the least powerful solution capable of solving your problem

Functional Frontend Architecture 101

Core Concepts

Pure functions
&

Unidirectional
data flow

Pure function

A pure function is a function that:

1. given a same set of params, always returns a same value

2. has no side effect

3. requires absolute immutability

Functional Frontend Architecture 101

image from: https://www.fpcomplete.com/blog/2017/04/pure-functional-programming

Components Tree

Non-unidirectional

images from css-tricks.com

Functional Frontend Architecture 101

Unidirectional data flow

images from css-tricks.com

Functional Frontend Architecture 101

Functional Frontend Architecture 101

Free-style mutation + asynchronicity = DOOMED! 

Is it for you?

Benefits

Predictability

Reproducibility

Modularity

Testability

Is it for you?

Trade-offs

In FFA, you must describe:

1. application state as plain objects and arrays.

2. changes in the system as plain objects.

3. the logic for handling changes as pure functions.

4. components in a declarative way

Is it for you?

Declarative

1. Tell computer what the result should look like

2. You write expressions

3. Functions are mathematical functions

Imperative

1. Tell computer how to achieve a result in steps

2. You write statements

3. Functions are coroutines

Is it for you?

Principle of

*power* and *principle*

or PPAP

Building blocks

1) a pure view function

2) a pure state function

building blocks

View Function V

view = V(state)

building blocks

State Function R

nextState = R(previousState, nextAction)

building blocks

State Function R

currentState = actions.reduce(R, initialState)

building blocks

State + View

currentView = V(actions.reduce(R, initialState))

building blocks

State + View

consumableState = S(rawState)

In real-life apps, view needs data to be transformed before being consumed. We need another pure function `S` that:

currentView = V(S(actions.reduce(R, initialState)))

building blocks

Dynamic View

When to change the view

Changes arrive in many forms:

1. user interactions with the view
2. data arrival from server
3. timer ticks

But in general they are events.

dynamic view

How to change the view

In the formula we formed before:

• V, S and R are pure functions
• initialState is a constant object that never changes
   

The only way to change view, is to update the "array of actions" when an event occurs

currentView = V(S(actions.reduce(R, initialState)))

dynamic view

Pushing event to "array of actions"

while (true) {
  event = waitForEvent();
  actions.push(event);
}

dynamic view

Changes as plain objects

action = A(event)

while (true) {
  event = waitForEvent();
  actions.push(A(event));
}

dynamic view

The ultimate formula

the ultimate formula

the ultimate formula

Bonus: Reactivity

Reactive Functional Programming

• Reactive Function Programming = Extension of FP
• RFP solves absolute immutability problems
• Everything is a stream
• Stream is just a representation of value over time
• You might be using it without even knowing so

bonus: reactivity

Actions as a stream

while (true) {
  action = actionCreator(waitForEvent())

  actions$.next(action)

}

bonus: reactivity

View as a subscription

  actions$
    .scan(reducer)
    .startWith(initialState)
    .map(selector)
    .map(view)
    .subscribe(setHTML)

bonus: reactivity

The ultimate reactive formula

events$

  .map(actionCreator)
  .scan(reducer)
  .startWith(initialState)
  .map(selector)
  .map(view)
  .subscribe(setHTML)

while (true) {
  events$.next(waitForEvent());
}

bonus: reactivity