The document discusses application state in various frameworks and architectures. It covers what constitutes application state, examples of state in REST and client-server apps, and state management in approaches like data in the DOM, Backbone collections, Angular scopes, in-memory databases, FRP, and more persistent solutions. It also discusses related topics like reactivity, consistency, performance, transactions, accountability of changes, and manipulating and saving state.

1. Application state
tomas.kulich@vacuumlabs.com

2. Some background

3. What is application state

4. What is application state
All the data that determines how application
looks and how application behaves

5. Application state of a REST­based
web­page
typical REST architecture:
● DB
● session?
● client's URL
● cookies
server
client
What about some JS widget?

6. Application state of a typical
heterogeneous server/client app
● some objects here and there
● event listeners installed here and there
● private attributes, local vars in hidden
scopes, ...
● DOM
● plus all of the RESTfull stuff

7. function counter(init){
var curr=init;
return function(){
return curr++;
}
}

10. What can REST teach us
● state is concentrated in a very FEW places,
everything else is a FUNCTION of state
● state is accessible to many parts of code (although
there should be some rules to who­can­do­what)
● state is mutated in a “nice” way
– ACID, transactions
– it does not matter how many threads do we have
● (plain) objects are poor in holding mutable state

11. Wait, but...
● I shouldn't create objects?
● I shouldn't manipulate DOM?
● What CAN I do?
● Can I even code, pleeeeease?

12. Data in
DOM
(pure
jquery)
Collection
/ smart
object
(Backbone
)
Angular
­ish
scope /
model
In
memory
DB
Signals,
FRP
Persistent
Epochal
state
Query language poor good good perfect good good
Reactivity no yes yes no yes yes
­consistency
N/A no quite
good
N/A perfect perfect
­performance
N/A good dirty
checks
N/A perfect perfect
­transactional
N/A no mostly
yes
N/A yes yes
Accountability no ~yes no ~yes no ~yes
Manipulation
­dump
hard easy hard easy hard easy
­save
/ load / time
travel
hard&cost
ly
costly hard&co
stly
costly quite fine fine

13. Data in
DOM
(pure
jquery)
Collection
/ smart
object
(Backbone
)
Angular
­ish
scope /
model
In
memory
DB
Signals,
FRP
Persistent
Epochal
state
Query language
Reactivity
­consistency
­performance
­transactional
Accountability
Manipulation
­dump
­save
/ load / time
travel

14. Data in
DOM
(pure
jquery)
Collection
/ smart
object
(Backbone
)
Angular
­ish
scope /
model
In
memory
DB
Signals,
FRP
Persistent
Epochal
state

15. ● Data in DOM (pure jQuery)
● Some “smart” data structure, such as Backbone
collection
● Angular­ish
scope
● In memory DB
● Signals, FRP
● Persistent state, Epochal time model

16. var Player = Blackbone.Model.extend({
initialize:
function(){
this.on( "change:name", this.changeName);
this.on( "change:age", this.changeAge);
},
changeName:
function(prev, val, options){
// this is a glitch and it is BAD thing
console.log("name: " + this.get("name") +
"whole name: " +
this.whole_name);
this.set({'whole_name', this.name + ' '+
this.surname});
},
});
var daz = new Player( {name:"Gaz", age:33});
daz.set( {name:"Daz"});

17. Signals, FRP
x'=x+1
y'=y+1
tot=x+y
mouse click
key press

18. FRP references
● ELM language
● a LOT of papers (Deprecating the Observer Pattern with Scala.React)
● Angular approach: http://teropa.info/blog/2013/11/03/make­your­own­angular­part­1­scopes­and­digest.
html

19. Query language
Reactivity
­consistency
­performance
­transactional
Accountability
Manipulation
­dump
­save
/ load / time
travel

20. Query language
● direct working with objects (maps)
– usually OK with some fine helpers
● SQL, datalog, MongoDB QL

21. Reactivity/Observability
● How do we address this in REST?
– well, we don't..
– Typically, we refresh / poll

22. Reactivity: Consistency
● Programmers deserves stability
– aka: Programátori si zaslúžia istoty
– can partially­updated
state be observable?
Glitches are bad.

23. Reactivity: transactional
jozo.set({name: "jozin z bazin"});
jozo.set({age: 18}); // wanna get some naughty pics
jozo.set({name: "jozo again"});
● How many notifications there'll be?
● How many do we want?
● Can we somehow perform all the changes as one atomical change?

24. var Player = Blackbone.Model.extend({
initialize:
function(){
this.on( "change:name", this.changeName);
this.on( "change:age", this.changeAge);
},
changeName:
function(prev, val, options){
// this is a glitch and it is BAD thing
console.log("name: " + this.get("name") +
"whole name: " +
this.whole_name);
this.set({'whole_name', this.name + ' '+
this.surname});
},
});
var daz = new Player( {name:"Gaz", age:33});
daz.set( {name:"Gaz"});

25. Reactivity: performance
● Let var a={name: 'jozo', age: 16};
How to tell, that a changed? old_a===new_a?
1. Encapsulate and intercept variable setters
­may
resolve in ugly API
­this
may still leave glitches there
2. Perform dirty checking
­React
or Angular do this
­performance
may suffer

26. Accountability of changes
● Who is responsible for changing of some piece of state?
1. Anyone, who feels it's a good idea
<input value = {{x | transform1}} >
<input value = {{x | transform2}} >
2. There exists a dedicated controller for this piece of state
­such
as Flux's store

27. Manipulation
state.dump(); // EVERYTHING is here
file.write(curr_state);
// poor man's undo
curr_state_index­­;
var state = states[curr_state_index];
app.render(state);

28. Data in
DOM
(pure
jquery)
Collection
/ smart
object
(Backbone
)
Angular
­ish
scope /
model
In
memory
DB
Signals,
FRP
Persistent
Epochal
state
Query language poor good good perfect good good
Reactivity no yes yes no yes yes
­consistency
N/A no quite
good
N/A perfect perfect
­performance
N/A good dirty
checks
N/A perfect perfect
­transactional
N/A no mostly
yes
N/A yes yes
Accountability no ~yes no ~yes no ~yes
Manipulation
­dump
hard easy hard easy hard easy
­save
/ load / time
travel
hard&cost
ly
costly hard&co
stly
costly quite fine fine

29. http://www.infoq.com/presentations/Are­We­There­Yet­Rich­Hickey

30. Author: Rich Hickey

33. Thank you for your attention
● this is not just about web anymore!
● check out Dart User Group on FB