[<<][ui][>>][..]
Thu Aug 17 21:57:01 EDT 2017

Microshocks? :) Anwyays, status quo stuff..

React: make the feedback loop bigger, so circular stuff gets "ironed
out" into pure functional dependencies (compute view directly from
model on each update).

I like that idea, but it is also terribly unpractical, and for my
current app I want to write most of the login in Erlang, server side,
with client side being fairly dumb, close to DOM.

But doing this for a bit I do wonder about all these architectural
patterns.  What is the real point behind MVC and MVVM etc...  So many,
so it seems there is little consensus.



https://stackoverflow.com/questions/667781/what-is-the-difference-between-mvc-and-mvvm

The basic MVCVM guidelines we follow are:

    Views display a certain shape of data. They have no idea where the
    data comes from.

    ViewModels hold a certain shape of data and commands, they do not
    know where the data, or code, comes from or how it is displayed.

    Models hold the actual data (various context, store or other
    methods)

    Controllers listen for, and publish, events. Controllers provide
    the logic that controls what data is seen and where. Controllers
    provide the command code to the ViewModel so that the ViewModel is
    actually reusable.


In my case:
- View = HTML (initial render + update)
- ViewModel ?
- Model = obvious
- Controller = events

MVC: Think database, HTML pages, and code inbetween


The main thrust of the Model/View/ViewModel architecture seems to be
that on top of the data (”the Model”), there’s another layer of
non-visual components (”the ViewModel”) that map the concepts of the
data more closely to the concepts of the view of the data (”the
View”). It’s the ViewModel that the View binds to, not the Model
directly.

some more here
https://russelleast.wordpress.com/2008/08/09/overview-of-the-modelview-viewmodel-mvvm-pattern-and-data-binding/

But really, not much the wiser.

Let's work from first principles.  The applications I'm writing are
all interfaces to procedures that happen over time.  What they do is:

- to display current configuration
- allow it to edit
- start procedure
- visualize state changes as procedure progresses until done
- optionally, provide output as a document

What works well here is to build the editor separately.  Have it do
input validation.  The rest of the application does not need to
interfere apart from specifying consistency (types and possibly other
constraints).

Procedure starts are just buttons starting processes.  This is the
"model change event" coming from the ui.

Progress updates are translations of events coming from the model.

Download is trivial: a one-shot render of the current model state.


There are two controllers, each corresponding to its own views
- The editor, linking data store and constraints to display
- The sequencer: start, display notifications, output document.


What I'm doing is more like MVVM, because the view does not talk to
the model directly.  Anways, the boundaries are fuzzy.  I have code
that generates a representation by querying the model and filling in
data templates to initialize the view (which has some methods that
only do display and event generation).  So maybe this is more like VM.

https://martinfowler.com/eaaDev/PresentationModel.html

  Represent the state and behavior of the presentation independently of
  the GUI controls used in the interface

  Presentation Model pulls the state and behavior of the view out into
  a model class that is part of the presentation.

So React is PM, but with a larger feedback cycle.

https://news.ycombinator.com/item?id=10773824



[Reply][About]
[<<][ui][>>][..]