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

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

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

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

    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

All functions in Haskell are curried by default

Your `add2` uses a tuple instead of currying whereas `add1` is already curried. In ghci:

    Prelude> (+) 3 4 == (+ 3) 4
    True

    Prelude> let add3 = (+ 3)
    Prelude> add3 5
    8

uncurry converts a curried function to a function on pairs.

windmove is probably it -- https://www.emacswiki.org/emacs/WindMove

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.

I think my intent might have come across wrong here.

The "states" aren't related to container/dumb components or data-fetching/selection logic. They're purely about rendering the state for a given segment of the page. Perhaps this article[0] might help convey my intent. It's more about how to render "we didn't get data from that one endpoint for this section of the page" or "we're waiting for the data to show up", etc.

[0] https://medium.com/swlh/the-nine-states-of-design-5bfe9b3d6d...

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>

   <PersonRenderer person={data.person} />

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

FWIW webpack's docs are getting much better for v2

You can use something like dataloader[0] or haxl[1] to help with this issue.

[0] https://github.com/facebook/dataloader

[1] https://github.com/facebook/Haxl

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.

If you go the docker-machine route, you can do the following.

    brew install docker-machine
    docker-machine create --name myserver ...digital-ocean-options
    eval $(docker-machine env myserver)
    docker ps

* install docker-machine

* provision a droplet with docker on it (you can also use test.docker.com to use an RC instead of the latest release)

* set your local shell env to point docker to said machine

* use the docker client to interact with said machine

I also use docker-for-mac and a similar process to spin up swarm-mode clusters. You can also ssh into the machine if you need to by `docker-machine ssh myserver`

[0] https://docs.docker.com/machine/drivers/digital-ocean/

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.

Having React on a static blog makes it easier to share component libraries that you've built up on other projects (perhaps SPAs) with said static blog.

It also allows the use of React's ecosystem, such as react-helmet[0], which makes it easier to change the meta tags and title on the page when rendering.

[0] https://github.com/nfl/react-helmet

As someone who is also building a React-based SSG, what do you believe makes sitegen's design superior to other React SSG's?

  Location: SF
  Remote: Yes/Preferably (6+ years of remote experience)
  Willing to relocate: No
  Technologies: JS(Babel), React, Haskell, Docker
  Résumé/CV: christopherbiscardi.com/resume.pdf
  Email: chris@christopherbiscardi.com

- Static Site Generator based on Relay/GraphQL and Webpack.

  * https://github.com/superawesomelabs/leo

- Content about creating a product with microservices(Docker), Haskell's Servant and Relay/GraphQL

React Router has been iterating towards better APIs for advanced use cases (server-side rendering, code splitting, relay (and other lib) integration, etc). Having used it in projects spanning the above use cases, the evolution of the API has been welcome change.

I'm also happy to see codemods and other AST manipulations (such as babel plugins) gaining popularity. Similar to eslint's --fix, codemods are making repetitive changes easier across large codebases.

I've been using lost for a few months now. Even if you don't use it it's worth taking a look. (built with PostCSS)

We use it at $work in an "isomorphic" context along with react-router[0] and fluxible[1]. I'm very happy with it and the ecosystem developing around it. Using React also provides an interesting lead-in to native apps with react-native.

We transpile all of our JS with babel as well. I'd be happy to answer any more specific questions as well.

[0] https://github.com/rackt/react-router [1]: https://github.com/yahoo/fluxible

For Haskell, Hayoo[0] works well

[0] http://hayoo.fh-wedel.de/?query=.%3A

The link for OSX points to `new-www`.haskell.org. I'm sure the old site still links to haskell platform.

After looking into this I've come to the conclusion that rewriting the JavaScript to handle events through React's system is the best way to include Foundation's JS components. (This is something I'm planning to do with Foundation-for-Apps since I won't be using Angular).

That said, the styles are still usable without modification and you could tell React to not handle pieces of the DOM in some cases for the existing JS.

You could use this list to discover [other keyword] if you are unfamiliar with the landscape. (For example, Isomorphic applications)

I find it no more complicated than things such as figuring out things like clearfixes were in the beginning.

Thanks for starting this. It's currently making my life much easier.

As an additional datapoint, Haskell's Snap Framework implements O(log n) routing like this: https://github.com/snapframework/snap-core/blob/master/src/S...

Agreed, but there are some issues there as well. (The "database" row could easily be labeled "postgres" for example).

Are you saying that large SQL strings isn't a code smell if the application is dynamically putting them together? That seems like DSL/Query Builder territory to me. Perhaps you could share an example?

That is actually currently being contested by React and .jsx.

That said, I've seen multiline abused for writing SQL queries as well, which would have been better off being written in a separate .SQL file and `fs.read` into a string with a descriptive var name. (Ignoring that massive SQL strings is a code smell imo).

https://twitter.com/chrisbiscardi

Haskell, JavaScript, YouTube, building things.

(Willing to help anyone learning Haskell. Just tweet at me.)