alfonsomunozpomer

// https://github.com/alfonsomunozpomer/react-fetch-mock

import React from 'react'
import fetchMock from 'fetch-mock'
import Enzyme from 'enzyme'
import {shallow, mount, render} from 'enzyme'
import Adapter from 'enzyme-adapter-react-16'

Enzyme.configure({ adapter: new Adapter() })

jimschubert

if (!String.prototype.repeat) {
  // polyfill from https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/repeat
  String.prototype.repeat = function(count) {
    'use strict';
    if (this == null) {
      throw new TypeError('can\'t convert ' + this + ' to object');
    }
    var str = '' + this;
    count = +count;
    if (count != count) {

andrewmclagan

import React, { Component, PropTypes } from 'react';
import { reduxForm, Field } from 'redux-form';

export class CreateUser extends Component {

  static propTypes = {
    createUser: PropTypes.func.isRequired,
    initialValues: PropTypes.object,
    submitting: PropTypes.bool.isRequired,
    invalid: PropTypes.bool.isRequired,

scott2b

"""REST principles state that we should version at the resource level. Both the version and the content-type of a
resource should be specified in the Accept header. But many developers prefer an approach which contains API
versions in the URL.

The approach in this gist finds a happy medium. Resource level versioning is provided, with resources being
specified for both version and content-type. Convenience URLs for API version levels are also configured, with each
API version being a specific set of versioned resources.

vendor-specified content types are configured in the form of vnd.namespace.Resource+mimetype. Routes for each of
these are configured as well as generic routes for the appropriate content type with the resource version that is