linter-elm-make
Always Compile Main: Yes
You can have the main paths set per project with file linter-elm-make.json
and content like:
{
"mainPaths": [
"src/elm/Main.elm"
]
linter-elm-make
Always Compile Main: Yes
You can have the main paths set per project with file linter-elm-make.json
and content like:
{
"mainPaths": [
"src/elm/Main.elm"
]
-- Assuming we have a list of items in the model (type alias Model = { items : List Item } | |
-- where Item is a record like { id : Int, name : String } | |
-- this goes in the view and generates an html dropdown | |
select | |
[ onSelect ValueSelectedMsg ] | |
(List.map (\item -> option [ value (toString item.id) ] [ text item.name ]) model.items) | |
targetSelectedIndex : Json.Decoder Int |
The power of a Static Typed language can seem magical at first. But the goal here is to take a tiny peak behind that curtain.
Elm's implementation of JSON parsing is type safe and how it achieves that can seem like a mystery. Even though I got the code to work, it took me a while to fully understand how it works.
I'm writing it down here for 2 reasons. To help others gain a greater understanding of Types and so I don't forget what I learned.
# To show hot code uploading, we first need to build a simple phoenix project so we can see it happen in real time. | |
# Start by making a new phoenix project | |
$ mix phoenix.new hotcode | |
# Go into the directory | |
$ cd hotcode | |
# Add exrm dependency to mix.exs file | |
{:exrm, "~> 1.0.3"} |
Use these rapid keyboard shortcuts to control the GitHub Atom text editor on macOS.
var allDone = function(done){ // takes a callback that will be called as callback(errors, values) when all async parallel operations are finished. | |
var context = {task: {}, data: {}}; | |
context.end = function(e,v){ return done(e,v), done = function(){} }; // this can always be called if you want to terminate early, like because an error. | |
context.add = function(fn, id){ // if the async operation you are doing replies with standard fn(err, value) then just pass in a string ID, else your own callback and ID. | |
context.task[id = (typeof fn == 'string')? fn : id] = false; | |
var next = function(err, val){ | |
context.task[id] = true; // good, we're done with this one! | |
if(err){ (context.err = context.err || {})[id] = err } // record errors. | |
context.data[id] = val; // record the values. | |
for(var i in c.task){ if(c.task.hasOwnProperty(i)){ // loop over the async task checker |
This document is a collection of concepts and strategies to make large Elm projects modular and extensible.
We will start by thinking about the structure of signals in our program. Broadly speaking, your application state should live in one big foldp
. You will probably merge
a bunch of input signals into a single stream of updates. This sounds a bit crazy at first, but it is in the same ballpark as Om or Facebook's Flux. There are a couple major benefits to having a centralized home for your application state:
sudo -i | |
cd | |
apt-get install build-essential checkinstall && apt-get build-dep imagemagick -y | |
wget http://www.imagemagick.org/download/ImageMagick-6.8.7-7.tar.gz | |
tar xzvf ImageMagick-6.8.9-1.tar.gz | |
cd ImageMagick-6.8.9-1/ | |
./configure --prefix=/opt/imagemagick-6.8 && make | |
checkinstall |
# Original Rails controller and action | |
class EmployeesController < ApplicationController | |
def create | |
@employee = Employee.new(employee_params) | |
if @employee.save | |
redirect_to @employee, notice: "Employee #{@employee.name} created" | |
else | |
render :new | |
end |