cyclejs

To conform better with web components (such as in the Polymer framework), the API for custom elements in Cycle has been changed from:

h('my-element', {attributes: {age: 30}});

to

h('my-element', {age: 30});

Where the definition of my-element used to be:

var MyElementComponent = Cycle.createView(function (Attributes) {
  // do something with Attributes.get('age')
};

it should now be (this is not part of the breaking change, just a rename of the argument in order to express better the new change in semantics):

var MyElementComponent = Cycle.createView(function (Properties) {
  // do something with Properties.get('age')
};

The reason for this breaking change is that: you might want to specify properties that are not under {attributes: ...} but still use them internally in the component implementation. For instance, in v0.10 you had to do {attributes: {style: {color: color}} where style would be translated to Attributes.get('style$') and this doesn't make sense since normal elements in virtual-dom such as div should use the API {attributes: {...}, style: {color: color}} with style outside of attributes.

• Update virtual-dom to 1.3.0
• Minor fix to Renderer behavior when replacing event handlers

Improved implementation for custom elements: there are no more container elements on the DOM for every custom element.

To register a custom element, you must provide a View, not just a DataFlowNode. This is minor breaking change. You need to replace Cycle.registerCustomElement('my-element', SomeDataFlowNode) with Cycle.registerCustomElement('my-element', SomeView).

RxJS updated to 2.3.24
virtual-dom updated to 1.1.0

Fixed bug: replacement mutation leakage from Views #67

Fixes bug where custom elements couldn't be used inside custom elements #64

Breaking change to the API related to custom elements

Register the custom element on Cycle object, not on the Renderer:

// v0.8.x (before)
var renderer = Cycle.createRenderer('.container');
renderer.registerCustomElement('mybutton', dataFlowNode);

// v0.9.0 (now)
Cycle.registerCustomElement('mybutton', dataFlowNode);

This change should persist also when HTMLRenderer arrives, for server-side rendering. Cycle.registerCustomElement() will instruct all instances of Renderer and all instances of HTMLRenderer to replace the tagName with the dataFlowNode implementation.

• Fixes a bug related to custom elements, #62

Major breaking changes to the API

Updated virtual-dom to 1.0.0.

No more interfaces array when declaring DataFlowNodes.
Interfaces are completely removed as a requirement for DataFlowNodes. Instead, use a getter to access properties of input DataFlowNodes, as such model.get('name$'). When ES6 Proxy is available in browsers, we will use it to implement the getter and recover the original API of model.name$. For now we must rely on explicit getters.

Removed events array required output for Views.
Interaction events are dynamically detected whenever they are used by, e.g., Intents.

Removed circularInject(), enhanced usage of inject()
Cycle.circularInject() was removed, but now a.inject(b) will return b so you can make circular dependencies using Intent.inject(View).inject(Model).inject(Intent).

Replaced 'ev-click' with onclick for exported interaction events in Views.
We now favor the DOM's native way of working rather than virtual-dom jargon. Also the dom-delegator dependency was removed as consequence.

In summary, before in v0.7.0:

var View = Cycle.createView(['name$'], function (model) {
  return {
    vtree$: model.name$.map(function (name) {
      return h('h1', {'ev-click': 'nameClicks$'}, name);
    }),
    events: ['nameClicks$']
  };
});

Cycle.circularInject(Model, View, Intent);

Now in v0.8.0:

var View = Cycle.createView(function (model) { // no interface array
  return {
    // notice model.get('name$') instead of model.name$
    vtree$: model.get('name$').map(function (name) {
      return h('h1', {onclick: 'nameClicks$'}, name); // onclick
    })
    // no more events array
  };
});

Intent.inject(View).inject(Model).inject(Intent); // no more circularInject()

• Custom elements can export interaction events
• Custom elements are now registered at the Renderer, not at the Cycle top-level object. This is a breaking change.
• Fixed DataFlowSource #54

• Fixed critical bug with the Renderer
• Updated virtual-dom to 0.0.24
• Updated browserify to 8.0.2

Has critical bug, use v0.6.9 instead

• Preliminary support for custom elements, see docs
• Updated RxJS to 2.3.22

• Better AMD support, see PR #41
• API creates actual JavaScript 'class' instance for DataFlowNode, DataFlowSource, DataFlowSink, instead of just an object without prototype.

• Fixed issue #39 of incorrect validation of event forwarding in Views

• Fixed dist file exposing absolute paths, by downgrading browserify to 5.10

• Fixed View throwing error when vtree (or child) is undefined

• Updated virtual-dom to 0.0.23

• Fixed issue #33 with Renderer inject
• Fixed DataFlowSink's implementation
• Improved View type checking on vtree$

Breaking changes

• Renamed all define___ functions to create___ in the Cycle API
• Replaced renderEvery() with Cycle.createRenderer().inject()

Improvements

• Introduced DataFlowSink for containing side effects, e.g. Renderer

Bug fixes

• Reverted virtual-hyperscript to 4.5.0 to solve bugs with hooks

Breaking changes

• Renamed BackwardFunction to DataFlowNode
• Renamed Cycle.link() to Cycle.circularInject()

Improvements

• renderEvery() can now receive a DOM element, beside a DOM selector string
• Added Rx as shortcut in Cycle root object
• Cycle.circularInject can receive multiple (2 or more) DataFlowNodes as inputs
• Updated Rx to 2.3.18, updated virtual-hyperscript to 4.6.0
• View throws plenty of instructive errors

Bug fixes

• Fixed model.clone(), view.clone(), inject.clone()

• Multiple inputs can be injected in a BackwardFunction (or a Model, View, or Intent) issue #5