data-logic-view v1.1.1

Data -> Logic -> View

This project is kind of a concept that has been written to be minimal and fully usable.

It is similar to MVC (or MV*). It follows the approach that no matter what is being developed, this should work anywhere that meets the following requirements:

• Does something with the end piece of data - View
• Retrieves data - Data (or data provider)
• Performs some kind of logic on that data - Logic

A project written using this approach would follow the following flow:

• Initialise a machine - more on that below
• Begin the application/journey/whatever with machine.exec(someKindOfDataThatTheViewShouldHaveAtTheStart)
• view.callback() is called with the following Event {"key": "start", value: someKindOfDataThatTheViewShouldHaveAtTheStart}
• View callback should listen for the start event, one approach would then be to send a new event requesting data from Data and listen for that event

From this point the application can begin doing whatever it is meant to do. Both Data and View have machineCb() and genEvent().

Generate Event

The generate event function is used to initialise a new event object.

Using genEvent will register the event in the machine, allowing for it to be cleared when it expires.

An event that is somehow created without using this function will result in an error being thrown from machineCb().

To use genEvent, run this.genEvent(key, value, from) from either view or data, if an event is somehow created from logic, another error will be thrown.

Parameters

• key - the key that will be listened for
• value - the value that will be sent along with the event, the idea is that the view can send any data it has and data will set the value being sending the event back.
• from - either 'view' or 'data', this tells the machine what direction to send it.

Machine Callback

The machine callback is how an event is passed along the process, below is an example of how it is used:

• Generate an event using genEvent
• this.machineCb(event)
• This will be passed to Logic.callback, which will then pass it back to machineCb, which will pass it in the correct direction.

Structure

The structure should follow:

• View - the View is responsible for doing something with the data that is received and nothing else
• Data - Data is responsible for fetching and sending data and nothing else
• Logic - Logic is only responsible for transforming, or making other decisions based on the data it is given from either the View or Data
• Machine - The job of the Machine is to communicate between the data/view/logic

This essentially means that the view should be 'dumb' and just ask for data and output the response, data should be 'dumb' and only do what it's told (get or send data) and logic is 'smart' but can only work with what it is given.

In my opinion this structure can lead to clean, easy to understand code, and it means that each piece of the application can only do it's job and nothing else.

Exports

View, Data, and Logic are designed to be extended, callback must be a function but should be replaced with your own function if you want your application to work.

Machine is designed to be used as is.

• Machine
• View
• Data
• Logic

Event - unexposed, passed between data, logic, view via machine

Holds data as it travels from view to logic to data and back.

Value is the only property that should be modified once created.

Public - only listing values that matter for usage

• key
• value
• fromView - boolean
• fromData - boolean

View

As mentioned above, the view should be 'dumb'. This is why it can only request for data and do something with that data.

The callback function is passed an event which it can either listen for a specific key to perform a specific action, or it can display whatever the event value is. (It's up to you, whoever you are)

Public

• callback(event)
• constructor(machineCallback, generateEvent)
• dispose()
• machineCb()
• genEvent()

Data

Data should also be 'dumb', it's only job is to wait until it is asked for data and retrieve that data, it can also send data without a request, this can be used to listen to updates for example.

The callback function works the same as View.

Public

• callback(event)
• constructor(machineCallback, generateEvent)
• dispose()
• machineCb()
• genEvent()

Logic

Logic should be 'dumb' but 'smart' at the same time. It's job is to wait until it receives an event, transform the data and then send the event back to the machine.

This is the reason it is not given the ability to create events, only to send them on.

The callback function works the same as View.

Public

• callback(event)
• constructor(machineCallback)
• dispose()

Machine

The machine is like a master, it controls the flow of events.

It also has an interval that checks if an event has expired and if so, removes it from the flow.

Each event, when generated, is stored in _events with the expiration as (Date.now() + this._eventTimeout). The event timeout can be defined in the constructor options.

The flow is started with exec() which is demonstrated above.

Public

• callback(event) - handles events
• genEvent(key, value, comingFrom) - returns an Event registered in _events
• dispose() - deregister interval, clean up events, etc
• constructor(opts) - set everything up
• exec(initialArgs) - calls _view.callback(genEvent('start', initialArgs, 'machine'))

Contructor options

The constructor is must be passed an options object, which is merged with the below default options:

{
    view: BaseViewConstructor,
    logic: BaseLogicConstructor,
    data: BaseDataConstructor,
    eventExpires: 60000
  }

###Private

• _events
• _view
• _data
• _logic
• _sendTo()
• _cleanup()
• _eventTimeout
• _cleanupInterval