Data models contain the entirety of application state (from the elm-lang guide - "The point of the model is to capture all the details about your application as data." )
A model could be as simple as a plain javascript object
const model = {}
Elm-style data models encourage easy data binding
// @todo make enterprise ready
const msg = ( fn ) => {}
// data model pattern based on an elm-style mvu
const model = {
loading: function( msg ) {
return msg( () => {
return
} )
},
failure: function( msg ) {
return msg( () => {
return
} )
},
success: function( msg ) {
return msg( () => {
return
} )
}
}
const view = ( model, msg ) => {
switch msg.status
case 'loading'
model.loading( msg )
break
case 'failure'
model.failure( msg )
break
case 'success'
model.success( msg )
break
}
Discrete event payloads and functional composition are not central to the data model pattern.
This data model is created inside an IIFE and event logic is abstracted away. We're a state machine and several steps away from inventing a reactive system.
// @todo make enterprise ready
const model = ( function() {
let dataModel = {
count: 0
}
const modelEvents = function( dataModel ) {
return {
counter: function( _ ) { ++dataModel.count }
}
}
return modelEvents( dataModel )
} )()
<div id="div" data-counter="0"></div>
Now we can easily poc two-way data-binding on the dataset attribute.
function view( model ) {
let _el = document.getElementById('div')
let _clonedEl = _el.cloneNode( true )
for ( let prop of model ) {
if (model.hasOwnProperty ( prop ) {
_el.addEventListener( 'click', () => {
_clonedEl.dataset[ model[ prop ] ] = model[ prop ]( _el.dataset[ model[ prop ] ] )
})
}
}
return _clonedEl
}
no side effects!