Immutable Data and TypeScript in an Ember.js Application

IMMUTABLE DATA AND TYPESCRIPT
IN AN EMBER.JS APPLICATION

INTRO
Hi, I’m Bill, on the internet my name is… > PIXELHANDLER

JUST YESTERDAY THREE KITTENS SHOWED UP AT HOME
Two will be leaving very soon 

I like the kitten
at the top, #1
The options are:
1. Cool cuddly
2. Way relaxed
3. Super active

These are the
Tacos that I eat
on Tuesday:
The meats are:
1. Fish
2. Pork
3. Chicken

INTRO
 Warning: this topic is not found in any of the current
Ember.js cow paths; or among the “safety of the herd”
 Well, except for that part of… using a framework built with
great tooling and testing
 Walkthrough an approach to using immutable data and
static type analysis in an Ember.js app
 And, why you would not want to do the above

EXAMPLE APP - “ON BOARDING”
YOU KNOW ONLINE REGISTRATION

Immutable Data and TypeScript in an Ember.js Application

EXAMPLE APP: ON BOARDING
 This is not the use case, but rather a simple example that
everyone is familiar with
 The goal of the on-boarding app is to kick off a long
running task, e.g. register a user for a system.
 Perhaps the result would be to confirm email then set up
two-factor authentication.
 That is beside the point.

EXAMPLE APP: ON BOARDING
In addition to a practical review of code using ember-cli-
typescript and an approach to create immutable data
models (without Ember.Object), the on-boarding app has
some nice test examples using ember-native-dom-helpers,
and async/await (ember-maybe-import-regenerator),
mocking Fetch with Sinon.js, and a simple http-mock
endpoint so we don’t actually need a server.

INSPIRATION
OR MAYBE PERSPIRATION, NOT SURE YET

INSPIRATION: ELM LANG
 Elm Lang application architecture…
 Model- state of the app
 Update- change the state;
 View- present the state
 https://guide.elm-lang.org/architecture/

INSPIRATION: THE CLEAN CODER HIMSELF
 Uncle Bob said I should learn functional programming…
 “The bottom line is this. Functional programming is
important. You should learn it.” - Robert C. Martin (Uncle Bob)
 http://blog.cleancoder.com/uncle-bob/2017/07/11/PragmaticFunctionalProgramming.html

INSPIRATION: REACT
 Flux architecture …
 An application architecture for React utilizing
a unidirectional data flow
 https://github.com/facebook/flux/tree/master/examples

INSPIRATION: GLIMMER.JS
 To write maintainable, understandable components, we
recommend that you embrace the Immutable Pattern:
 Save component state as an "atom" in a tracked property
on the component.
 To change state, replace the root "atom" with a
new copy of the state.
 https://github.com/glimmerjs/glimmer-
website/blob/master/src/guides/tracked-properties.md#the-immutable-
pattern

MOTIVATIONS
USES CASES FROM A REAL WORLD SCENARIO

MOTIVATIONS: USE CASES FOR IMMUTABILITY
 Current project uses stateless
APIs and eventual
consistency
 Two users in the system, who
push changes back and forth
 Reload the app with current state of
user interface, e.g. which section of a
form the user is working on, which
fields are expanded, which fields are
checked, which fields are valid, which
button is enabled, etc. This is transient
state that can be derived (or reduced)
from values and configuration data for
a dynamic form interface.

 Aside from reload, push the
data between users and present
the same transient state, you
see what I see (based on the
data choices I or you make)
 Approach a solution (problem domain) by
modeling the user interface completely,
and use components that simply read from
their respective chuck of the model (state)
 Focus on data structures for a solution and
model the overall behavior vs. focus on
various isolated behaviors across many
components

 Create a solution that is
driven by configuration
that can meet various
custom requirements in a
multi-tenant system
 Use interfaces and static type
analysis to improve real time
feedback to the developer while
creating a solution
 Using types as well as interfaces
helps to improve documentation of
the problem/solution

 Close to real time
persistence of data changes
as users interact
 Since some changes affect other
properties in the state, use a consistent
way to model change sets
 Process changes when cloning a model
instance to generate the next
representation of that document for a
given screen in the web application

 Handle differing concerns
of the UI data model,
presentation and
persistence
 Presentation is derived from
persistent data, well data that will
eventually settle
 Instead of using bindings just set a
new model for the current screen
after processing data changes
generated by the user or another
user in the system

TYPESCRIPT: TESTING
Acceptance Test
 Used interface for mock Fetch
response
Service Unit test
 Used interfaces and types for items
under test as well as mocking
Fetch
Component Integration Test
 Used types for items under test
and spies in text context
Controller Unit Test
 Use model interface and type for
controller dependency, the model

CURRENTLY THE TS COMPILER IS PRETTY NOISEY

TYPESCRIPT: APPLICATION
Route
 Used interface for route protoype
and types for function params
Controller
 Used interface for controller
protoype and types for function
params, variable assignment
Service (Repo)
 Used interface for repository
method and types for function
params and variable assigment
Model
 Didn’t use Ember.Object, custom
interfaces, types to compose the
model of the user interface

SHOW ME THE MONEY, I MEAN THE CODE…
https://gitlab.com/pixelhandler/on-boarding/commits/master
The model uses a factory for nested models in the interface, hold on opening an editor

WRAP UP: TAKE-AWAYS
 There are some gotchas, but the benefits for the uses cases
I had were worth coding for those special cases:
- Component lifecycle create, destroy, etc.
- Create a new model without interrupting the user input
 There is much more code in the model layer of the app

WRAP UP: TAKE-AWAYS
 Less use of Ember practices which are based around
computing properties
 Don’t do this if your use cases do not demand it
 I’m curious why the components have to be destroyed
when the primitive properties of the model/state are the
same

ANY QUESTIONS
I STILL HAVE A BUNCH TOO 
Bill Heaton | @pixelhandler | https://pixelhandler.com

Immutable Data and TypeScript in an Ember.js Application

Recommended

More Related Content

Similar to Immutable Data and TypeScript in an Ember.js Application (20)

Recently uploaded (20)

Immutable Data and TypeScript in an Ember.js Application