This is roughly the same test run in both casper and nightwatch.
const t = require("tcomb"); | |
// imstruct is a tcomb type builder that internally builds an | |
// Immutable.Record object, but applies tcomb's type system to it | |
const imstruct = require("../util/imstruct"); | |
const Person = imstruct({ | |
name: t.String, | |
age: t.Number | |
}); |
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])) { |
// note there may be a better way to abuse flexbox than this :) | |
var React = require('react-native') | |
var { View, TextInput } = React | |
var BorderedInput = React.createClass({ | |
getInitialState() { | |
return { i: 0 } | |
}, |
Below are a small collection of React examples to get anyone started using React. They progress from simpler to more complex/full featured.
They will hopefully get you over the initial learning curve of the hard parts of React (JSX, props vs. state, lifecycle events, etc).
You will want to create an index.html
file and copy/paste the contents of 1-base.html
and then create a scripts.js
file and copy/paste the contents of one of the examples into it.
class DisableMigrations(object): | |
def __contains__(self, item): | |
return True | |
def __getitem__(self, item): | |
return "notmigrations" | |
MIGRATION_MODULES = DisableMigrations() |
This is a response to Bill Fisher regarding experience with Flux:
@abdullin Also, can you clarify what you mean by "solution structure"? I am thinking about revising the examples soon.
Currently all flux samples (that I've seen) group files into folders based on technical similarity. For example, stores go with stores, action creators reside in the same folder shared with the other action creators.
This pattern works quite well for smaller projects. It feels especially good for the sample projects of various MVC frameworks, when you have just a bunch of controllers, models and views.
However, as we discovered on some production projects, such approach doesn't scale well. At some point you end up with dozens of technically similar files per folder and logically messy solution.
While the following structure is not an absolute requirement or enforced by the tools, it is a recommendation based on what the JavaScript and in particular Node community at large have been following by convention.
Beyond a suggested structure, no tooling recommendations, or sub-module structure is outlined here.
lib/
is intended for code that can run as-issrc/
is intended for code that needs to be manipulated before it can be used
Custom recipe to get OS X 10.10 Yosemite running from scratch, setup applications and developer environment. I use this gist to keep track of the important software and steps required to have a functioning system after a semi-annual fresh install. On average, I reinstall each computer from scratch every 6 months, and I do not perform upgrades between distros.
This keeps the system performing at top speeds, clean of trojans, spyware, and ensures that I maintain good organizational practices for my content and backups. I highly recommend this.
You are encouraged to fork this and modify it to your heart's content to match your own needs.
from django.core.conf import settings | |
class DbgResponse(object): | |
def process_response(self, request, response): | |
"""Add html, head, and body tags so debug toolbar will activate.""" | |
if request.GET.get('dbg') and settings.DEBUG: | |
cnt = response.content | |
if '<body>' not in cnt: | |
response.content = '<html><head></head><body>%s</body></html>' % cnt | |
if 'content_type' in response._headers: |