biscarch

All functions in Haskell are single-argument functions. Multiple arguments are syntactic sugar. The syntax sugar can make it confusing to talk about but if you define an `add` function that takes two arguments x and y:

    add x y = x + y

it's sugar for multiple single-argument functions.

    add = \x -> \y -> x + y

When examining it this way, the `g` function above would translate to

    g = \(x, y) -> 2 * x + y

Which is a function taking a single tuple argument. It is still "default curried" but the argument being passed in is a single argument rather than multiple so we don't expand it to multiple single-arg functions. Perhaps it is more illustrative to show the definition as the single argument it is rather than using haskell's destructuring to pull x and y out of the tuple.

    g tuple = 2 * (fst tuple) + (snd tuple)

and a ghci session for completeness:

    Prelude> let g (x, y) = 2 * x + y
    Prelude> g (1,2)
    4
    Prelude> let y tuple = 2 * (fst tuple) + (snd tuple)
    Prelude> y (1,2)
    4

So when we say that Haskell functions are "curried by default", what we're referring to is roughly the underlying single-argument nature of haskell functions.

link-rest fits the use case where you might not be able to transition the REST endpoint to be behind a GraphQL API (and thus be server-side resolvable which is definitely preferable) due to organizational or other concerns.

I've been super excited about Chrome headless but haven't had a chance to dig into using it yet. The api here looks amazing for getting started without getting lost in the weeds. It'd be fairly trivial to hook this up to a Slackbot and to get on-demand screenshots of various pages on my websites, etc.

Loading (and error, etc) state should be the responsibility of the component doing the content rendering, not the parent. So the ConditionalSpinner component:

   <ConditionalSpinner renderIf={data}><PersonRenderer person={data.person} /></ConditionalSpinner>

Could be written better as:

   <PersonRenderer person={data.person} />

Where PersonRenderer would be defined as such:

   class PersonRenderer extends Component {
     render() {
       if(this.props.person) {
         return <div>personcontent</div>
       }
       return <LoadingIndicator/>
     }
   }

Given this, I'm still not sure how an If "component" would be achieved (and further, you'd need an Else or a Switch component anyway if going down this route). Maybe you could explain the benefits of such a path?

FWIW webpack's docs are getting much better for v2

You link to a comment which indicates serialization is a potentially breaking issue. This is a tradeoff that does not affect the routine behavior of redux but may affect advanced use cases such as allowing user upload of action history for bug reports.

Regardless of serialization/replay-ability, the core of the suggestion is to `import` some constant instead of using raw strings. Symbols have the benefit of forcing an import, whereas a list of constants that reference strings can be "bypassed" by writing the correct string in a random file. In fact, the redux actions documentation uses the following example of this pattern as the first example.

``` // fileA const ADD_TODO = 'ADD_TODO'

//fileB { type: ADD_TODO, text: 'Build my first Redux app' } ```

It is possible to use Symbols instead of strings, which yields some nice improvements in terms of no longer allowing construction of actions with potentially misspelled strings, etc.

Right, except support for that has to be built into the static site generator you're using. In the React case, the user can choose how they want to do it without the SSG author caring at all. I will also say that in the case of frontmatter, react-helment is a far more powerful solution which allows defining at any point in the tree, not just a layout partial.

In addition, the React way allows you a full language to handle import/export for "templates" instead of relying on a hampered template language/partials implementation.

The key here isn't the specific instance of frontmatter, it's having the flexibility to use everything one might use to build a SPA to target static sites. This re-use of existing solutions and skills is important.