hagemann

function slugify(string) {
  const a = 'àáâäæãåāăąçćčđďèéêëēėęěğǵḧîïíīįìıİłḿñńǹňôöòóœøōõőṕŕřßśšşșťțûüùúūǘůűųẃẍÿýžźż·/_,:;'
  const b = 'aaaaaaaaaacccddeeeeeeeegghiiiiiiiilmnnnnoooooooooprrsssssttuuuuuuuuuwxyyzzz------'
  const p = new RegExp(a.split('').join('|'), 'g')

  return string.toString().toLowerCase()
    .replace(/\s+/g, '-') // Replace spaces with -
    .replace(p, c => b.charAt(a.indexOf(c))) // Replace special characters
    .replace(/&/g, '-and-') // Replace & with 'and'
    .replace(/[^\w\-]+/g, '') // Remove all non-word characters

WebReflection

// https://webreflection.medium.com/using-the-input-datetime-local-9503e7efdce
Date.prototype.toDatetimeLocal =
  function toDatetimeLocal() {
    var
      date = this,
      ten = function (i) {
        return (i < 10 ? '0' : '') + i;
      },
      YYYY = date.getFullYear(),
      MM = ten(date.getMonth() + 1),

zambon

_.mixin({
  deeply: map =>
    (obj, fn) =>
      map(_.mapValues(obj, (v) => {
        if (_.isPlainObject(v)) {
          return _.deeply(map)(v, fn);
        } else if (_.isArray(v)) {
          return _.map(v, item => _.deeply(map)(item, fn));
        }
        return v;

jlongster

A lot of people mentioned other immutable JS libraries after reading my post. I thought it would be good to make a list of available ones.

There are two types of immutable libraries: simple helpers for copying JavaScript objects, and actual persistent data structure implementations. My post generally analyzed the tradeoffs between both kinds of libraries and everything applies to the below libraries in either category.

Libraries are sorted by github popularity.

Persistent Data Structures w/structural sharing

gaearon

function mapValues(obj, fn) {
  return Object.keys(obj).reduce((result, key) => {
    result[key] = fn(obj[key], key);
    return result;
  }, {});
}

function pick(obj, fn) {
  return Object.keys(obj).reduce((result, key) => {
    if (fn(obj[key])) {

tlrobinson

// give it a name so it reuses the same window
var win = window.open(null, "redux-devtools", "menubar=no,location=no,resizable=yes,scrollbars=no,status=no");

// reload in case it's reusing the same window with the old content
win.location.reload();

// wait a little bit for it to reload, then render
setTimeout(function() {
    React.render(
        <DebugPanel top right bottom left >

aldendaniels

React now supports the use of ES6 classes as an alternative to React.createClass().

React's concept of Mixins, however, doesn't have a corollary when using ES6 classes. This left the community without an established pattern for code that both handles cross-cutting concerns and requires access to Component Life Cycle Methods.

In this gist, @sebmarkbage proposed an alternative pattern to React mixins: decorate components with a wrapping "higher order" component that handles whatever lifecycle methods it needs to and then invokes the wrapped component in its render() method, passing through props.

While a viable solution, this has a few drawbacks:

1. There's no way for the child component to override functionality defined on the higher order component.

djspiewak

Git DMZ Flow

I've been asked a few times over the last few months to put together a full write-up of the Git workflow we use at RichRelevance (and at Precog before), since I have referenced it in passing quite a few times in tweets and in person. The workflow is appreciably different from GitFlow and its derivatives, and thus it brings with it a different set of tradeoffs and optimizations. To that end, it would probably be helpful to go over exactly what workflow benefits I find to be beneficial or even necessary.

• Two developers working on independent features must never be blocked by each other
  • No code freeze! Ever! For any reason!
• A developer must be able to base derivative work on another developer's work, without waiting for any third party
• Two developers working on inter-dependent features (or even the same feature) must be able to do so without interference from (or interfering with) any other parties
• Developers must be able to work on multiple features simultaneously, or at lea

sebmarkbage

import { Component } from "React";

export var Enhance = ComposedComponent => class extends Component {
  constructor() {
    this.state = { data: null };
  }
  componentDidMount() {
    this.setState({ data: 'Hello' });
  }
  render() {

chenglou

Interesting part (unmounting & API) is at the end if you're not interested in the rest =).

Stress Tests

This animation proposal is just an attempt. In case it doesn't work out, I've gathered a few examples that can test the power of a future animation system.

1. Parent is an infinitely spinning ball, and has a child ball that is also spinning. Clicking on the parent causes child to reverse spinning direction. This tests the ability of the animation system to compose animation, not in the sense of applying multiple interpolations to one or more variables passed onto the child (this should be trivial), but in the sense that the parent's constantly updating at the same time as the child, and has to ensure that it passes the animation commands correctly to it. This also tests that we can still intercept these animations (the clicking) and immediately change their configuration instead of queueing them.

2. Typing letters and let them fly in concurrently. This tests concurrency, coordination of an array of ch