Gerrit0

This is a first attempt at a high level restructure of TypeDoc. There are almost certainly issues with the proposed design that I'm missing or haven't resolved yet. Some of these include

1. How should users modify the JSON output? #930
2. A lot of events are used by TypeDoc's current design, this offers a lot of flexibility for plugins to attach to an event and modify an object at any part of its lifecycle, but makes debugging painful since they are also heavily used internally. Which events should be retained, and which should be removed?
3. Does it make sense for readers to declare their options in the constructor? It is nice to tie the code that uses the option and the code that declares it together, but this could cause problems when using the api programatically.
4. Should some readers exist by default? (TsConfig, TypeDoc)

Goals in this first pass:

1. Define the primary interfaces required to write a CLI

mootari

Components

Instantiation

Components that extend from ChildableComponent may specify a childClass. Any included/required component extending from that class will automatically be added to the parent component's _defaultComponents and instantiated along with its parent. This behavior is provided by the Component decorator.

Converter Components

All default converter components extend from ConverterComponent. When the converter component is instantiated any converter component that has been required at this point will be added to it.

justinwoo

Reposted from Qiita

For almost a year now, I've been using this "flux" architecture to organize my React applications and to work on other people's projects, and its popularity has grown quite a lot, to the point where it shows up on job listings for React and a lot of people get confused about what it is.

Why I'm tired of using and teaching flux

There are a billion explainations on the internet, so I'll skip explaining the parts. Instead, let's cut to the chase -- the main parts I hate about flux are the Dispatcher and the Store's own updating mechanism.

If you use a setup similar to the examples in facebook/flux, and you use flux.Dispatcher, you probably have this kind of flow:

lygaret

define(function(require) {
    var React = require('react');

    var paramRegex  = /__(\d)+/;
    var parser      = new DOMParser();
    var errorDoc    = parser.parseFromString('INVALID', 'text/xml');
    var errorNs     = errorDoc.getElementsByTagName("parsererror")[0].namespaceURI;

    // turns the array of string parts into a DOM
    // throws if the result is an invalid XML document.

mgol

var ngAppElem = angular.element(document.querySelector('[ng-app]') || document);

window.$injector = ngAppElem.injector();
window.inject = $injector.invoke;
window.$rootScope = ngAppElem.scope();

// getService('auth') will create a variable `auth` assigned to the service `auth`.
var getService = serviceName =>
    inject([serviceName, s => window[serviceName] = s]);

piscisaureus

Locate the section for your github remote in the .git/config file. It looks like this:

[remote "origin"]
	fetch = +refs/heads/*:refs/remotes/origin/*
	url = git@github.com:joyent/node.git

Now add the line fetch = +refs/pull/*/head:refs/remotes/origin/pr/* to this section. Obviously, change the github url to match your project's URL. It ends up looking like this: