bahmutov

// following along https://medium.com/@luijar/kliesli-compositions-in-javascript-7e1a7218f0c4
const R = require('ramda')
const Maybe = require('ramda-fantasy').Maybe

// parse JSON string into object
// parse :: String -> Object | Null
function parse(s) {
  try {
    return JSON.parse(s)
  } catch (e) {

Undistraction

import { connect } from 'react-redux';
import React from 'react';

import { loadStepDataRequest } from '../../redux/actions';

import getStepByUid from '../../redux/selectors/getStepByUid';
import * as PropTypes from '../proptypes';

// Take state and feed in to component props

Undistraction

// proptypes.js

import React from 'react';

export const stepData = React.PropTypes.arrayOf(
  React.PropTypes.shape({
    title: React.PropTypes.string.isRequired,
    date: React.PropTypes.string.isRequired,
    filename: React.PropTypes.string.isRequired,
    colourAnalytics: React.PropTypes.arrayOf(

yang-wei

When receiving JSON data from other resources(server API etc), we need Json.Decode to convert the JSON values into Elm values. This gist let you quickly learn how to do that.

I like to follow working example code so this is how the boilerplate will look like:

import Graphics.Element exposing (Element, show)
import Task exposing (Task, andThen)
import Json.Decode exposing (Decoder, int, string, object3, (:=))

import Http

yang-wei

Should be work with 0.18

Destructuring(or pattern matching) is a way used to extract data from a data structure(tuple, list, record) that mirros the construction. Compare to other languages, Elm support much less destructuring but let's see what it got !

Tuple

myTuple = ("A", "B", "C")
myNestedTuple = ("A", "B", "C", ("X", "Y", "Z"))

HenrikJoreteg

Why would you want to do this? Because you often don't need more. It's nice to not have to think about your "router" as this big special thing.

Instead, with this approch, your app's current pathname is just another piece of state, just like anything else.

This also means that when doing server-side rendering of a redux app, you can just do:

var app = require('your/redux/app')
var React = require('react')

gaearon

// Written by @iclanzan
// All credit goes to him!

// You create the reducer like this:
// var reducer = createTimelineReducer('someName', someReducer, ['foo', 'bar']);
// And then whenever an action of type `foo` or `bar` happens it calls `someReducer` and adds the result to the timeline.
// Then to undo/redo you trigger an action of type `someNameUndo`/`someNameRedo`.

var defaults = require('lodash/object/defaults');
var capitalize = require('lodash/string/capitalize');

gaearon

import React, { Component } from 'react';
import { createStore, combineReducers, applyMiddleware, bindActionCreators } from 'redux';
import { provide, connect } from 'react-redux';
import thunk from 'redux-thunk';

const AVAILABLE_SUBREDDITS = ['apple', 'pics'];

// ------------
// reducers
// ------------

ohanhi

Learning FP the hard way: Experiences on the Elm language

by Ossi Hanhinen, @ohanhi

with the support of Futurice 💚.

Licensed under CC BY 4.0.

Editorial note

justinwoo

Reposted from Qiita

For almost a year now, I've been using this "flux" architecture to organize my React applications and to work on other people's projects, and its popularity has grown quite a lot, to the point where it shows up on job listings for React and a lot of people get confused about what it is.

Why I'm tired of using and teaching flux

There are a billion explainations on the internet, so I'll skip explaining the parts. Instead, let's cut to the chase -- the main parts I hate about flux are the Dispatcher and the Store's own updating mechanism.

If you use a setup similar to the examples in facebook/flux, and you use flux.Dispatcher, you probably have this kind of flow: