dwyl/learn-elm-architecture-in-javascript

:unicorn: Learn how to build web apps using the Elm Architecture in "vanilla" JavaScript (step-by-step TDD tutorial)!

learn-elm-architecture-in-javascript's Issues

Review with "Beginner's Mind"

We need this tutorial to be reviewed by a person who is reasonably new to both JavaScript and the Elm Architecture so that we can:

• confirm that the steps are clear
• check code is well explained
• ensure nothing is implied/assumed that should be explicit

@EdwardCodes please can you read through the instructions in this tutorial, try the examples and open any issues when anything is unclear? (thanks!)

Main Todo List View <section class="main">

The "Main" view in the Todo List Application displays the actual list.
Try it: http://todomvc.com/examples/vanillajs/

This is the HTML copied directly from the browser:

<section class="main" style="display: block;">
  <input class="toggle-all" type="checkbox">
  <label for="toggle-all">Mark all as complete</label>
  <ul class="todo-list">
    <li data-id="1533501855500" class="completed">
      <div class="view">
        <input class="toggle" type="checkbox">
        <label>Learn Elm Architecture</label>
        <button class="destroy"></button>
      </div>
    </li>
    <li data-id="1533501861171" class="">
      <div class="view">
        <input class="toggle" type="checkbox">
        <label>Build Todo List App</label>
        <button class="destroy"></button>
      </div>
    </li>
    <li data-id="1533501867123" class="">
      <div class="view">
        <input class="toggle" type="checkbox">
        <label>Win the Internet!</label>
        <button class="destroy"></button>
      </div>
    </li>
  </ul>
</section>

Acceptance Criteria

• Todo List items should be displayed as list items <li> in an unordered list <ul>.
• Each Todo List item <li> should contain a <div> with a class="view" which "wraps":
  • <input class="toggle" type="checkbox"> - the "checkbox" that people can "Toggle" to change the "state" of the Todo item from "active" to "done" (_which updates the model From: model.todos[id].done=false To: model.todos[id].done=true
  • <label> - the text content of the todo list item
  • <button class="destroy"> - the button the person can click/tap to delete a Todo item.

Note: the "toggle-all" (above the "main" list) is a separate issue/feature: #50

This issue is part of the TodoMVC Feature List [Epic] #48

ES5 confusion

The section on plain JS might be read as suggesting the project is in ES5, but I think (I may be wrong) property shorthand is ES6

Remove the callback()

Removing the callback might not be a simple thing for some beginners. Edit suggestion below:

  function signal(action) {          
    // return function callback() {     // comment out to remove callback 
      model = update(model, action); 
      view(signal, model, root);     
    // };                               // comment out to remove callback.
  };

Then refresh the browser and check the console.

TDD Reset the Counter

Adding the Reset action is good opportunity to write a test first!
As a user (counting things)
I want to reset the counter
So that I can start counting again from zero.

• Clicking the reset button in the UI resets the count to 0 (zero).

Subscriptions: How to "Listen" for Events and What to do ...

In order to have "Event Listeners" (so users can hit the [Enter] Key to create a Todo Item #55)
We need to add "Subscriptions" to Elm(ish).
see: https://www.elm-tutorial.org/en/03-subs-cmds/01-subs.html

Todo

• investigate/research if we need to register events each time the DOM is re-rendered
• write a test for subscriptions ... e.g:
  • [Up] & [Down] keyboard key press increases/decreases the counter.
• add subscriptions parameter to mount function
• invoke the subscriptions in mount depending on the outcome of initial research

required for: #55

Why? What? Who? How?

See: dwyl/learn-elm#82

Elm(ish) onClick Event/Function Attribute

In order to simplify event listeners in our TEA example apps,
I'm thinking that adding an onclick attribute to a given node and passing in the signal(action)
is the simplest way of keeping the view declarative.

This will be useful for both "delete" a todo item (which is a button) and incrementing a counter.

• add_attribute([function]) >> onclick=signal(action)

Tests won't load on local filesystem

GET file://code.jquery.com/qunit/qunit-1.18.0.css net::ERR_FILE_NOT_FOUND error is given if loading the test html page from local file system (not from a live-server).

This is because // is used in the script sources which will use file:// instead of http://.

https:// could be used instead of //.

<script src="https://code.jquery.com/qunit/qunit-1.18.0.js"></script>

instead of //code.jquery...

use of gifs / images

The two biggest pngs + the two biggest gifs totalled 1.7MB out of 3MB total for downloading the dwyl/learn-elm-architecture page. They definitely have advantages, but maybe consider

a) Linking to images
b) Linking to two different pages in a doc folder with or without images as the viewer prefers (I read github on mobile data a lot)

DELETE a Todo List item using the "cross" (button)

• should show the <button class="destroy"> on hover (over the item)
• Clicking/tapping the <button class="destroy"> sends the signal('DELETE', todo.id)
• DELETE update case receives the todo.id and removes it from the model.todos Array.

render_item renders the DOM for a Single Todo List item

Given the following HTML:

    <li data-id="1533501855500" class="completed">
      <div class="view">
        <input class="toggle" type="checkbox">
        <label>Learn Elm Architecture</label>
        <button class="destroy"></button>
      </div>
    </li>

Use Elm(ish) DOM functions (li, div, input, label and button)
to render a single Todo List item.

Acceptance Criteria

• Each Todo List item <li> should contain a <div> with a class="view" which "wraps":
  • <input class="toggle" type="checkbox"> - the "checkbox" that people can "Toggle" to change the "state" of the Todo item from "active" to "done" (_which updates the model From: model.todos[id].done=false To: model.todos[id].done=true
  • <label> - the text content of the todo list item
  • <button class="destroy"> - the button the person can click/tap to delete a Todo item.

Sample Test:

test.only('render_item HTML for a single Todo Item', function (t) {
  const model = {
    todos: [
      { id: 1, title: "Learn Elm Architecture", done: true },
    ],
    hash: '#/' // the "route" to display
  };
  // render the ONE todo list item:
  document.getElementById(id).appendChild(app.render_item(model.todos[0]))

  const done = document.querySelectorAll('.completed')[0].textContent;
  t.equal(done, 'Learn Elm Architecture', 'Done: Learn "TEA"');

  const checked = document.querySelectorAll('input')[0].checked;
  t.equal(checked, true, 'Done: ' + model.todos[0].title + " is done=true");

  elmish.empty(document.getElementById(id)); // clear DOM ready for next test
  t.end();
});

Run tests on CLI/CI ?

Run the tests on CI so we can independently confirm they are working?

view function in Todo List App

Now that we have the individual ("lower order") functions
render_main #51, render_item #52, and render_footer #53
for rendering the sections of the todo app,
we can write the view function to render the entire app!

With the main and footer "partial" views built, the overall view is rediculously simple:

To save on repetition, and illustrate just how simple the view is, this is the "HTML"
with the <section class"main"> and <footer class="footer"> partials replaced by invocations to the respective functions render_main #51 and render_footer #53:

<section class="todoapp">
  <header class="header">
    <h1>todos</h1>
    <input class="new-todo" placeholder="What needs to be done?" autofocus="">
  </header>
  render_main(model)
  render_footer(model)
</section>

Acceptance Criteria

View displays:

• <h1> containing the title text "todos".
• <input class="new-todo"> has placeholder text "What needs to be done?"
• <ul class="todo-list"> list of todo items has zero items by default.
• <footer> count is Zero when the app is first rendered with no todos in the model.

Split out the example code in section 5

At present there code sample in section 5 of the readme is quite a large block ...
https://github.com/dwyl/learn-elm-architecture-in-javascript/tree/bec517c23919c78a5ae72c42cfb9c4a3ea71ba88#5-read-through--break-down-the-code-in-the-example
we can split it out into 3 sections with corresponding commentary.

Picture of the Elm Architecture

https://twitter.com/rtfeldman/status/973382389035618304

I think it's worth adding this to the Readme as it's much more "friendly" than the "flow diagram".
(note: not as a "substitute" but as an "enhancement"...)

Do we *need* to "init"?

While re-reading the code (and preparing for "elmish") It occurred to me that we might be over-complicating things ...

Do we need an init function to initialise the DOM in:

learn-elm-architecture-in-javascript/examples/counter-reset/counter.js

Lines 69 to 85 in 814467e

	function init(doc){
	document = doc; // this is used for instantiating JSDOM. ignore!
	}
	/* The code block below ONLY Applies to tests run using Node.js */
	/* istanbul ignore next */
	if (typeof module !== 'undefined' && module.exports) {
	module.exports = {
	view: view,
	mount: mount,
	update: update,
	div: div,
	button: button,
	empty: empty,
	init: init
	}
	} else { init(document); }

e.g:

learn-elm-architecture-in-javascript/test/counter-reset.test.js

Line 10 in 075c4c4

init(document); // pass the JSDOM into counter.js

If we use https://github.com/rstacruz/jsdom-global in our tests, we should not need an init function.
I'm going to experiment with updating the counter-reset tests and see if I can remove the init function completely.

Typo in section 5.3

In section 5.3 there is a typo switch is written as swicth.

Happy to make a quick PR to fix this, but don't have rights on this repo.

Breaking It Down #1: Organizing Code with Model, View, and Octupus!

I am using the study of @nelsonic implementation of the Elm architecture in Javascript to motiviate myself to back-fill, extend, organize, and apply knowledge about constructing GUIs in the browser environment using Javascript.

First question in looking at the material for me is: if the Elm architecture with its update, model, view organization is the answer, then what is the question? To that end, the Udacity course on patterns of organising the code for GUI javascript apps, provided much needed background context: Javascript Design Patterens. The course starts with restructuring a naive sphaghetti-code implementation of a simple app with a just-using-Javascript implementation/interpretation of model-view-controller, before looking at using Knockout.js. If someone has little time, then there is an excellent summary of the basic ideas/principles of code organisation with the video Universal Organizational Concepts.

Incidentally, just watching the videos means that a lot more dwyl tutorials make sense with a straight read through, which indicates that the material above is information I was very much needing to backfill. One of the basic mistakes beginner resources make along with the abscence of teaching specification and testing is there are no words about organization. Thus one of the primary benefits of learning Elm for a front-end developer might just be the benefits of working within its tight constraints as a way of disciplining the mind. About the only introductory Javascript book which discusses code organisation is Get Programming with Javascript which implements model-view-controller from scratch through chapters 14. 15. 16. Just watching the Udacity course means I can now get a lot more out of those chapters than my first glance-through many months ago!

Also Gordon Zhu's free course Practical Javascript teaches Javascript from the ground up using seperation of concerns. Too, if my memory serves me right Leo Verou in construcing a JS/HTML/CSS implementation of Conway's Game of Life also used proper structure from the beginning in the Pluralsight course Play by Play: HTML, CSS, and JavaScript with Lea Verou, starting out with data structures (model) in the console and later on adding HTML and CSS (view)!

"Elmish" + Todo List Example?

Can we split the DOM-creation and mount code into it's own file elmish.js and use it as an opportunity to create a basic Todo List using TodoMVC styles?

Tasks

• Split any generic functions into a separate file called elmish.js (independently tested)
  • empty - Empty all DOM nodes
  • mount - mount the app to the root DOM node.
• DOM Creation Functions
  • <section>
  • <div>
  • <ul>
  • <li>
  • <input>
  • text
  • <h1>
  • <header>
  • <label>
  • <footer>
  • <span>
  • <strong>
  • <a>
• Router: e.g: /#/active #46
• localStorage #47
• "Helpers"
  • Attributes
    • id
    • class
    • data-id
    • for
    • type
    • autofocus
    • style
    • placeholder
    • href
    • checked
  • Child Nodes
• Biz Logic! #48

Saving / Retrieving Data to/from localStorage

TodoMVC saves the todolist items (list) to localStorage
so that it's still there if the page is refreshed or closed (and returned to).
try it: http://todomvc.com/examples/vanillajs

What is the "MVP" of this?

add CONTRIBUTING.md file to repo to encourage contributions

As a person who is new to the DWYL Org/Community 🆕
I need to know how to contribute to the project effectively 💭
so that I can start my journey towards Doing What I Love with my Life! ❤️ ✅ 😂

Markdown:

_**Please read** our_ [**contribution guide**](https://github.com/dwyl/contributing) (_thank you_!)

Note: these are line-separated but in the actual rendered page it's all one line.
see: https://github.com/dwyl/contributing/blob/master/CONTRIBUTING.md

Can we load the test-related Styles/Scripts using a single "loader" script?

e.g:

function div(divid, text) {
  console.log(divid, text)
  var div = document.createElement('div');
  div.id = divid;
  if(text !== undefined) {
    var txt = document.createTextNode(text);
    div.appendChild(txt);
  }
  console.log(div);
  return div;
}

function script(src){
  var script = document.createElement('script');
  script.type = 'text/javascript';
  script.setAttribute('src', src);
  console.log(script);
  return script;
}

function style(href) {
  var link = document.createElement('link');
  link.type = 'text/css';
  link.rel = 'stylesheet';
  link.href = href;
  return link;
}
document.body.appendChild(div('qunit'));
document.body.appendChild(div('qunit-fixture'));
  document.body.appendChild(script('//cdnjs.cloudflare.com/ajax/libs/blanket.js/1.1.4/blanket.js'));
(function() {
  // Load the QUnit CSS file from CDN - Require to display our tests
  document.body.appendChild(style('//code.jquery.com/qunit/qunit-1.18.0.css'));
  document.body.appendChild(script('//code.jquery.com/qunit/qunit-1.18.0.js'));

  document.body.appendChild(script('test.js'));
})();

1. No Todos, should hide #footer and #main

When there are No Todos, do not display the #main (list of todos) or footer (navigation):

refer to the 1st test on this list: https://github.com/tastejs/todomvc/tree/master/tests#example-output

Test

Add the following test to your test/todo-app.test.js file:

test.only('No Todos, should hide #footer and #main', function (t) {
  // render the view and append it to the DOM inside the `test-app` node:
  document.getElementById(id).appendChild(app.view({todos: []})); // No Todos

  const main_display = window.getComputedStyle(document.getElementById('main'));
  t.equal('none', main_display._values.display, "No Todos, hide #main");

  const main_footer= window.getComputedStyle(document.getElementById('footer'));
  t.equal('none', main_footer._values.display, "No Todos, hide #footer");

  elmish.empty(document.getElementById(id)); // clear DOM ready for next test
  t.end();
});

"Local copy" confusion

This comment reads "make local copies of the init parameters", but I believe that this is inaccurate.

In the codebase as written, I think it makes a local copy of model, but not update or view. The function probably shouldn't know that model will be pass-by-value anyway, and so should consider the possiblity it's not making a copy of any of those values.

Update version of JSDom to avoid out-of-date dependency badge :-|

https://david-dm.org/dwyl/learn-elm-architecture-in-javascript?type=dev

Toggle All Todo List Items

  <input class="toggle-all" type="checkbox">
  <label for="toggle-all">Mark all as complete</label>

Acceptance Criteria

• clicking/tapping the "toggle-all" checkbox will set the done=true on all todo list items.
• When toggle-all is set to checked then clicking/tapping it again will set all items done=false

This issue is part of the TodoMVC Feature List [Epic] #48

Unclear sections in the TDD portion

In section 9.1 the workshop suggests the reset action be named 'res', but then for the rest of the text lists it as 'reset'. There's a premade 'reset' css class so it definitely makes more sense to just keep it as 'reset' the whole way through.

Then in sections 9.4 and 9.5 when writing tests for the reset button UI, the expected behaviour is for the two newly written tests to fail, but what actually happens is test number 5 fails too:

Although sorting the test is an easy fix, it's not mentioned in the text so could easily be misconstrued by beginners as being due to them messing something else up.

Happy to make a quick PR if you want.

Prepare this Tutorial for "Publication"

We need to be a lot more systematic in how we share the content we produce.

Todo

• Tidy up the content removing anything superfluous!
• Produce the 5 min video
• Prepare the tweet with link to video and image

Question (for Inês...)

@iteles should we do our CMS/Blog MVP before publicising this content so that we get SEO from it?

The reason I have not previously prepared the "Content Launch Checklist" is because it requires a chunk of work from me where I tend to get pretty exhausted from writing the initial tutorial and just want to get "back" to my "real work" ... 😖 ⏳

Do we need to clarify "Uni-directional data-flow"?

In the Why? section, when explaining the benefits of the Model Update View architecture "Uni-directional data flow" is mentioned.

Uni-directional data-flow means "state" of the app is always predictable; given a specific starting "state" and sequence of update actions the output/end state will always be the same. This makes testing/testability very easy!

I am not sure, if, to somebody who just fills the prerequisites for this tutorial (basic JS knowledge, basic TDD knowledge, a computer, 30 minutes), that it is clear what uni-directional data flow is.

Do we need to clarify what it is further?
If we do think that it needs more clarification for someone of this level, is it important to have that information in this repo, or would a link to a separate explanation suffice?

Would love to get feedback from people going through this tutorial for the first time on this question!

Add explanation of signal -> callback function (closure)

https://developer.mozilla.org/en/docs/Web/JavaScript/Closures#Closure

[Epic] TodoMVC Feature List

Todo List Basic Functionality

A todo list has only 2 basic functions:

• Add a new item to the list
  • new list item created when the [Enter] key is pressed #55
• Check-off an item as "completed" (done/finished)
  • Click/tap on checkbox next to todo item

Add item and Check-off is exactly the "functionality"
you would have in a paper-based Todo List.

TodoMVC "Advanced" Functionality

In addition to these basic functions,
TodoMVC has the ability to:

• Un-check an item as to make it "active" (still to be done)
• Double-click/tap on todo item description to edit it.
• Mark all as complete
• Click X on item row to remove from list.

<footer> Menu > GOTO: #53

below the main interface there is a <footer>
with a count, 3 view toggles and one action:

• "{count} item(s) left":
  
  {store.items.filter(complete==false)} item{store.items.length > 1 ? 's' : '' } left
• Show All
• Show Active
• Show Completed
• Clear Completed > delete item.done === true

Routing / Navigation

Finally, if you click around the <footer> toggle menu,
you will notice that the Web Bowser Address bar
changes to reflect the chosen view.

When a route link is clicked

• update invokes route(model, title, hash) function which updates model.hash to the value of hash

• filter view based on model.hash

  • set <footer> view button as active
  • filter todo items based on selected view:
    • ALL: no filter
    • active: !item.done
    • complete: item.done === true

• Subscriptions for event handling e.g: keyboard press & navigation changes #57

use of the word model/state

Hi Nelson, Just wanted to raise a question on here.

Why call the argument in the update function model and then when calling the function have it defined as the state, could we just not call it model when calling it?

It is a minor thing but it may bamboozle a few beginner or am I being too cautious? what are your thoughts?

render_footer renders the <footer> element of Todo App

Todo App <footer> Element

Referring to the rendered HTML on http://todomvc.com/examples/vanillajs as our "guide":

there is:

• a <footer> element with
  • a <span> element which contains
    • a text node with: "{count} item(s) left".
  • a <ul> containing
    • 3 <li> elements each with
    • a link (<a>) which allow the "user" to filter which items appear in the <view>.
  • a <button class="clear-completed"> which will Clear all Completed items when clicked.

Dev Tools > Elements (inspector)

Copy-paste the rendered HTML

I "copy-pasted" of the rendered HTML from the Dev Tools:

<footer class="footer" style="display: block;">
  <span class="todo-count">
    <strong>2</strong> items left
  </span>
  <ul class="filters">
    <li>
      <a href="#/" class="selected">All</a>
    </li>
    <li>
      <a href="#/active">Active</a>
    </li>
    <li>
      <a href="#/completed">Completed</a>
    </li>
  </ul>
  <button class="clear-completed" style="display: block;">
    Clear completed
  </button>
</footer>

Technical Acceptance Criteria

• render_footer returns a <footer> DOM element which can be rendered directly to the document or nested in another DOM element.
• <footer> contains:
  • <span class="todo-count"> which contains
    • a text node with: "{count} item(s) left".
      pseudocode:
      {model.todos.filter(done==false)} item{model.todo.length > 1 ? 's' : '' } left
  • <ul> containing 3 <li> with the following links (<a>):
    • Show All: <a href="#/" class="selected">All</a>
      • class="selected" should only appear on the selected menu/navigation item.
        this should be "driven" by the model.hash property.
    • Show Active: <a href="#/active">Active</a>
    • Show Completed: <a href="#/completed">Completed</a>
  • <button class="clear-completed" style="display: block;"> will Clear all Completed items.
    pseudocode:
    var new_model = model.todos.filter(function(item) { return item.done === false})

This issue is part of the TodoMVC Feature List [Epic] #48

That's nice but how about some tests?! (Can we do it TDD?)

Let's write some Tests!!

Recommended Reading link: Unidirectional User Interface Architectures

Recommended/Further Reading link:
https://staltz.com/unidirectional-user-interface-architectures.html

Multiple Counters on the Same Page 😮

It occurred to me while applying the Elm Architecture to my little "side project": dwyl/time-mvp-node#33
That there's a "gap" in this tutorial, namely: how do we have a more "complex" model
(all the examples in the tutorial, currently have model as an int)

I propose that we: write an "exercise for the reader" to:
a) refactor the model in the "reset counter" example to use an Object
e.g: var model = { counters:[0] }
where the value of the first element in the model.counters Array
is the value for the single counter example.
b) using the var model = { counters:[0] } approach, display multiple counters on the same page.
c) write tests for the scenario where there are multiple counters on the same page.

Help People Realise that Learning the Elm Architecture will help them with React (Redux)!

Add a little section to the readme to remind people that learning the Elm architecture will help them building React.js Apps!!

Clarity on essence of TEA vs how it's implemented here

This is a really nice introduction to the Elm Architecture!

I have a couple of related questions:

1. Should it be made clear that the implementation here is provided as a concrete example of the Elm Architecture? I find that beginners sometimes get confused between whether an idea is some specific code (the implementation) vs something that is the pattern behind lots of pieces of code

2. There are a couple of places where the tutorial has to change the way it does things compared to how Elm does them. For example here we read

Actions are always defined as a String

This is the way Redux does it, and arguably makes sense in JS-land, but would be really awful in Elm-land. A bit of clarity on how this is an implementation of the core ideas + also a shift of language here ("We will always define actions as Strings) might stop some potential confusion

Add GIF of Counter Example

Add GIF of the counter in action so it's more engaging.

Typo in Section 5.1 - Mount Walkthrouh

https://github.com/dwyl/learn-elm-architecture-in-javascript#51-mount-function-walkthrough

Need to update explanation to reflect function arguments. ( no longer an object as first arg )

Rudimentary Routing in a Client-side Web Application: Why? What? How?

Routing in Web Application is surprisingly simple.
There are only a couple of functions we need to write but we want to achieve the following goals:

Acceptance Criteria

• URL (hash) should change to reflect navigation in the app
• History of navigation should be preserved and
  • Browser "back button" should work.
• Pasting or Book-marking a URL should display the desired content when the "page" is loaded

For: #44 "Elmish" Todo List Example

Model Update View (MUV) Diagram

Add diagram illustrating the uni-directional flow through MUV.

UX Feature Hitting the [Enter] (Return) key creates a new Todo List item

Technically there is no other way of adding a todo list item as there are no "submit" buttons.
So we need to have an event listener on the [Enter] key in order for the Todo List to function at all.

Acceptance Criteria

• document.getElementsByClassName('new-todo')[0].addEventListener("keyup" ...
  which creates a new todo item when the [Enter] is pressed.
  see: https://stackoverflow.com/questions/905222/enter-key-press-event-in-javascript
• if the <input class="new-todo"> is empty then ignore the [Enter] keypress.

This issue is part of the TodoMVC Feature List [Epic] #48
Depends on: #57

typo on the cloning project command

On the clone-this-repository section

git clone https://github.com/dwyl/learn-elm-architecture-in-javascript.git && learn-elm-architecture-in-javascript
should be (adding change directory commandcd ):

git clone https://github.com/dwyl/learn-elm-architecture-in-javascript.git && cd learn-elm-architecture-in-javascript

Breaking It Down #2: Javascript the Hard Parts, Closure, Scope, Execution Context, Callbacks, and Higher Order Functions

As stated elsewhere, my main purpose of studying the learn-em-architecture-in-javascript code was using the code to help me deliberately backfill gaps in my JavaScript knowledge, and after learning basic dom stuff, my main stumbling block was centered around how JavaScript actually executes code, i.e. what gets run and when and why. To that end, this free version of a Front Masters course is the best resource so far for answering my questions: https://www.youtube.com/playlist?list=PLWrQZnG8l0E5hMTpzCK8WjP3nJ93jUEyk

Too, it is a single coherent resource for defining the topics of closure, scope, execution context, callbacks, and higher order functions; topics without which it will not be possible to truly understand the code. Instead of someone having to go read numerous resources, and then gather them together, and then apply them to the code, it is all in one place within a single narrative.

And here is the FrontEnd masters workshop: https://frontendmasters.com/courses/javascript-hard-parts/

Review with "Beginner's Mind" #22

"@EdwardCodes please can you read through the instructions in this tutorial, try the examples and open any issues when anything is unclear? (thanks!)"

@nelsonic i´ve read through the instructions in this (awesome) tutorial (_the reasons to learn elm are very clear and very captivating) and tried the examples (explaining why the code is there and the meaning with the step-by-step comments is MEGA useful 🥇) but there´s a few things i didn't understand:

"9.1 Tests for Resetting the Counter (Update)"
"9.4 Write View (UI) Tests"

I didn't´t understand were do i put/write the tests in the script.. besides that everything is clear, each function (mount, signal, update, empty, button and view) has their own purpose in the app, we should use "pure" functions so we can have more control of the outputs (the "impure" js can be tricky).

Toward a Better Front End Architecture: Elm - Codemash 2017

https://youtu.be/EDp6UmaA9CM

Found this talk interesting/useful for "TEA". 😉

Markdown Fail

Markdown fail:

https://github.com/dwyl/learn-elm-architecture-in-javascript/tree/8097e4b753cdf099105c3d210fc0fe997c410c40#a-complete-beginners-guide-to-muv

Abstract superlatives

Mileage may vary, but I find language like

Anyone who knows a little bit of JavaScript and wants to learn how to organize/structure
their code/app in the most sane, predictable and testable way.

(from here) quite off-putting.

It's hard to provide evidence for things like "most sane", and anyway, the most sane way to organise something probably depends on the specifics of the thing you're trying to organise. There are definitely tonnes of advantages to the Elm Architecture, but I'm not sure it's the "most" anything.

Also, as a user, I would probably stop reading at this point because it looks quite dogmatic.