optimizely / nuclear-js Goto Github PK

http://developers.optimizely.com/nuclear-js/docs/ redirects to http://developers.optimizely.com/
Could this be due to the recent update to the dev docs @jordangarcia ?

evaluate, __hasStaleValue, __cacheValue, and __isCached all seems to be built on the assumption that two objects with the same hashCode()-result must be identical.
While making this assumptions obviously provides some performance-benefits, it may on occasion lead to completely wrong results.

For the getters, I'd propose that the result of toImmutable(getter) be stored and checked with Immutable.is(), but depending on usage patterns, doing something similar for state may have an unreasonable memory-overhead.

Hey @jordangarcia, it seems that our new dev site did cause our docs to not load anymore. We'll have to look into what caused this.
It was first reported in #96 by https://github.com/citelao.

I'd expect isGetter to assert that a getter is valid (e.g. composed only of strings, optionally a trailing function, or other getters). Instead, it tests that an array ends in a function.

Valid getters that fail this test

["path"]

Invalid getters that pass

[1, true, null, () => ({})]

A more robust test

function isGetter(value) {
  return isArray(value) && value.every(
    (item, i) =>    isString(item)
                 || (i === value.length - 1 && isFunction(item))
                 || isGetter(item)
  );
}

It passes all the current getter tests.

Getting this at line 46 of change-observer.js.

In Firefox the error is Unhandled promise rejection" TypeError: 'log' called on an object that does not implement interface Console

I'm using Babel as well, maybe this has something to do with it.

The docs don't mention whether Getters are recalculated every time, or just once between Store updates. It seems this implementation should allow at least per-update caching/memoization. Is that implemented/on the roadmap? Could this be mentioned in the docs?

Steps to reproduce:

1. Return null from a Store's getInitialState.
2. Dispatch an action that the store doesn't handle.

Expected result:

The store ignores the action.

Actual result:

Store handler must return a value, did you forget a return statement

In your examples, most of the KeyPaths are only a single level deep. Since you encourage breaking the data architecture into modules, I presume that this is often the case in heavier apps too.

Allowing the user to specify KeyPaths as Strings (while using Arrays for deeply-nested paths) would make the code a bit less verbose. It also would be consistent with the example for getDataBindings:

getDataBindings() {
  return {
    // can reference a reactor KeyPath
    items: 'items',
    taxPercent: 'taxPercent',

I clearly haven't tried Nuclear yet. If Strings are acceptable KeyPaths, the documentation should be updated to reflect that. If not, should they be? In any case, the KeyPaths used in getDataBindings should follow the same rules as the ones used in getters.

In the example, the taxPercent store is setup thusly:

this.on('setTaxPercent', function(percent, value) {
  return value
})

percent is a confusing name, since presumably both values are percentages. Since this is an example, clarity is especially important. I suggest state and payload, to maintain the convention used throughout the rest of the document. oldPercent and newPercent would also be good choices.

As React is moving away from mixins, it might make sense to start talking about alternatives. Maybe something along the lines of:

function nuclearComponent(Component, dataBindings, reactor) {
  return class NuclearComponent extends React.Component {
    constructor() {
      this.state = getState(reactor, dataBindings)
    }

    componentDidMount() {
      var component = this
      component.__unwatchFns = []
      each(dataBindings, function(getter, key) {
        var unwatchFn = reactor.observe(getter, function(val) {
          var newState = {};
          newState[key] = val;
          component.setState(newState)
        })

        component.__unwatchFns.push(unwatchFn)
      })
    }

    componentWillUnmount() {
      while (this.__unwatchFns.length) {
        this.__unwatchFns.shift()()
      }
    }

    render () {
        return <Component {...this.props} {...this.state} />;
    }
  }
}

Which you could then use like:

// ES7
@nuclearComponent(dataBindings, reactor)
class MyComponent extend React.Component {
    // ...
}

// ES6
class MyComponent extend React.Component {
    // ...
}

MyComponent = nuclearComponent(MyComponent, dataBindings, reactor)

• add instructions to setup repo and testing
• add section for code style
• add part about NOT checking in dist code

I personally like Vue's CONTRIBUTING.md

@bhamodi would you mind doing?

The underlying cause is the Utils.isFunction method returning false for Chrome 35 (confirmed).

Hi,

Nuclear looks incredibly exciting. I was wondering what the story around creating Isomorphic applications (same code for server and client) might look like.

Since events shouldn't be necessary, I would primarily hope that:

1. Using the Mixin won't break the application on the server.
2. getDataBindings could allow an alternative source on the server, OR getInitialState could work on the server, OR an alternative would be provided.

(I'm asking as someone who hasn't yet built complex isomorphic apps and hasn't yet used Nuclear, I apologize for any gaps in my knowledge!)

Thanks!

It seems that the react render mixin does NOT use shouldComponentUpdate().
This is pretty surprising because I really expected this... Instead, the components
call setState() if their state observable sees a difference in state...

So when I get this correctly, stateless components are true as the developer
does not have to deal with component state... everything is managed by nuclear; but
state is obviously there - spread all over the component tree.

Doesn't this hidden state all over the component tree trigger setState() more than really
required or does nuclear intelligently detect the topmost component to call setState() for...
leading to a single subtree re-rendering?

It would be great to have updated examples (Todos) to better experiment with nuclear...

Basically calling setState() deep in the component hierarchy is nice to perform
high performant updates on components - but as often propagated, state should
live as high in the component hierarchy as possible... (and therefore cause
a complete re-render of the whole app; something that immutable data makes
fast due to efficient use of shouldComponentUpdate()...)

What is wrong with my understanding of nuclear???

reactor.observe only triggers on changes. It seems like it should trigger immediately using the current result of the getter. Otherwise, if you don't know the present state and don't want to leak memory, you have to do something like this:

var stopObserving;

var onValue = (value) => {
  var completed = doStuffWith(value);

  if (completed)
    stopObserving();
};

onValue(reactor.evaluate(getter));
var stopObserving = reactor.observe(getter, onValue);

Instead of simply reactor.observe(getter, onValue).

This could either be corrected by default, corrected with a flag or new method (like observeImmediately), or left as is. What do you think?

Is there any functionality available to setup stores with some initial data, stored in a global variable or passed as a parameter to an App.initialize(spec) method. I've seen on other Flux implementations that have similar behavior, e.g.:

Flux.start({
  StoreName: { /* store data */ },
  OtherStore: { /* store data */ }
});

Raul.

• add .eslintrc
• add grunt eslint command
• add pre-commit hook to enforce style

Hello,

I was at your lightening talk at this meetup, and I seem to remember this library enabled version tracking (aka change history).

I'd like to add "Undo" functionality to an in-brower app, and from the docs, I see this:

Stores are self managing state, providing a single canonical place to define the behavior a domain of your application over time.

But is that talking about tracking high-level state history (like the browser back button needs to return to the previous "page") or granular-level change history (like an undo button needs).

Thanks!

I just spent ages wondering why my installation wasn't working before realising I had used npm install nuclearjs which is a completely different thing. /facepalm

Is it perhaps worth putting a note in the readme highlighting this is not the package named "nuclearjs" on npm?

Currently, eslint is not being enforced upon committing.

I have run into a problem where one of my Nuclear app observe callbacks is being called when a different Store is changed than the one it is observing.

My server-api.js file has the following observe call:

initialize: function() {
  reactor.observe('query.query', sendQuery);
}

The sendQuery function is defined like this:

let sendQuery = (query) => {
  console.log("Issuing server request!");
  Actions.setRequestInProgress(true);
  // etc.
  // Then in an async callback
    Actions.setRequestInProgress(false);
};

My DataStore has the following code to register a listener for setRequestInProgress (the QueryStore does not register a listener for setRequestInProgress):

this.on(Const.setRequestInProgress, (state, isInProgress) => {
  console.log('data-store: set isInProgress to ' + isInProgress);
  return state.set('requestInProgress', isInProgress);
});

I have a button that triggers an action that changes query.query. As expected, this triggers my sendQuery method since it was observing query.query.

The Actions.setRequestInProgress(true) action triggers a change in a the DataStore (in the data. requestInProgress keypath) so I can keep track of whether there is a query in progress.

The problem is that while handling the data change for setRequestInProgress, my sendQuery function gets called again, even though nothing new changed in query.query. It's as if it gets called for any data change if there is already a change in progress from an earlier Action.

I was able to work around this by changing my actions in sendQuery to use setTimeout like so:

setTimeout(Actions.setRequestInProgress.bind(null, true), 0);

It seems to me that this should not be necessary though.

Am I doing something weird/wrong or is this a defect?

Thanks!

Ken

I see you can make getters get data from multiple stores. Can you also have getters get data from multiple modules? (Haven't used nuclear yet, just investigating it)

Seems like a strange thing to put in a frontend framework. Why not use the utilities in Immutable.js, or at least split these out?

Gets rid of every pull request claiming the tests failed.

Is there a solution for this use case?

Congrats, Nuclear is a very interesting project. Now while eagerly trying to integrate it with an existing project based on this isomorphic react stack:

https://github.com/irvinebroque/isomorphic-hot-loader

I get this error message:

TypeError: Object # has no method 'groupCollapsed'
at Object.exports.dispatchStart (/home/mydir/isomorphic-hot-loader/node_modules/nuclear-js/dist/nuclear.js:793:12)

I guess this is due to different rendering environments (server/client)?

Unfortunately I have no idea how I could fix this, any suggestion?

This works:

import {Immutable} from 'nuclear-js';
const List = Immutable.List;

class CommentList extends React.Component {
  static propTypes = {
    comments: React.PropTypes.instanceOf(List).isRequired
  }
}

But this does not:

import {List} from 'immutable';

class CommentList extends React.Component {
  static propTypes = {
    comments: React.PropTypes.instanceOf(List).isRequired
  }
}

Warning:

Failed propType: Invalid prop `comments` supplied to `CommentList`, expected instance of `List`. Check the render method of `UpdatePage`.

Is that supposed to happen? I'm using Webpack, nuclear-js 1.0.5, and immutable 3.7.3.

The docs have gotten much better for Nuclear but it is unclear when looking through the example repos (todomvc, and tetris) the conventions for creating a reactor. The docs use Nuclear.Reactor passed an object with a stores property containing properties that map to stores created with Nuclear.Store. Todomvc uses Nuclear.Reactor which gets passed an object with actions and state properties. Also, it seems that the Todomvc version of nuclear is the only version compatible with the nuclear-react-mixin.

jordangarcia/nuclear-react-mixin#1

Tetris uses Nuclear.createReactor() which I'm assuming is antiquated, along with reactor.attachCore, reactor.bindActions and reactor.computed.

From this I'm confused on Nuclear best practices, and if only the current docs should be followed.

Following your basic example, I added a form to the component with three input fields for "name", "price" and "quantity". The handleSubmit function for the form looks like this:

  handleSubmit:function() {
    var submitData = {name: this.state.name, price: this.state.price, quantity: this.state.quantity};
    reactor.dispatch('addItem', submitData);
  }

The dispatch itself works perfectly as expected but the components view with the list of items gets not updated/rerenderd.

The console log:

Dispatch: addItem
client.js:30403 payload
client.js:30404 Object {name: "Cheese", price: "2", quantity: "5"}
client.js:30412 Core changed: items
client.js:30419 Dispatch done, new state: Object {items: Array[3], budget: Infinity, taxPercent: 20}

What is the recommended way to get the reactor instance into each component that needs to use it?

I initially just put it on the window object, which works, but that isn't really a good idea. I can pass it into my react-router as below:

Router.run(routes, Router.HistoryLocation, function (Handler, state) {
  React.render(<Handler reactor={reactor}/>, document.body);
});

which gives me the reactor on this.props.reactor, but that is too late for passing into NuclearReactMixin(reactor).

I could setup a singleton wrapper component and import/require that I suppose. What do you guys do?

Is nuclear-js using singletons? I took https://github.com/optimizely/nuclear-js/tree/rest-api-example/examples/flux-chat, added mock-data2.js and mounted it twice to, a different part of the web page.

https://gist.github.com/hipertracker/6aa9ef3dd513471f72c4

It looks like those components are not isolated and share some state. :(

How to reuse the same component? (The only difference would be data passed to it)

Including lodash as a dependency has two undesirable side effects:

1. Greatly increases the dist size of nuclear
2. Forces you to use lodash as your application utility library

My preferred solution would be to simply make lodash an optional dependency. I understand that the authors may want to keep using lodash functions, so as an alternative, only include the lodash functions currently being used by nuclear:

var each = require('lodash.foreach'); // instead of require('lodash').each;

Thoughts @dtothefp ?

You're using Immutable-js 3.4.3, but the latest version is 3.7.3. I specifically miss the isEmpty() function on lists.

Have you considered using cursors into the Immutable? It might simplify things a lot, and even give a performance boost.

Enable automated browser testing on travis-ci

• setup karma-sauce-launcher
• add sauce tokens to the travis-ci environment
• add saucelabs testing badge to README

(nuclear-js version 0.5.0-rc4 from npm)

I'm currently testing my nuclear-js stores via mocha, and I keep seeing this output whenever I call reactor.get() using any given KeyPath:

iterable.length has been deprecated, use iterable.size or iterable.count(). This warning will become a silent error in a future version. Error
    at Record.Object.defineProperty.get (/Users/rod/Documents/GitHub/ripple-connect-client-app/node_modules/nuclear-js/dist/nuclear.js:1627:20)
    at isArray (/Users/rod/Documents/GitHub/ripple-connect-client-app/node_modules/nuclear-js/dist/nuclear.js:6848:64)
    at Function.module.exports.isKeyPath (/Users/rod/Documents/GitHub/ripple-connect-client-app/node_modules/nuclear-js/dist/nuclear.js:735:7)
    at evaluate (/Users/rod/Documents/GitHub/ripple-connect-client-app/node_modules/nuclear-js/dist/nuclear.js:768:16)
    at Reactor.get (/Users/rod/Documents/GitHub/ripple-connect-client-app/node_modules/nuclear-js/dist/nuclear.js:194:13)
    at getConsolidatedAppState (/Users/rod/Documents/GitHub/ripple-connect-client-app/app/scripts/shared/NuclearTestUtils.js:32:36)
    at Context.setUp (/Users/rod/Documents/GitHub/ripple-connect-client-app/app/scripts/shared/NuclearTestUtils.js:60:26)
    at callFn (/Users/rod/Documents/GitHub/ripple-connect-client-app/node_modules/mocha/lib/runnable.js:266:21)
    at Hook.Runnable.run (/Users/rod/Documents/GitHub/ripple-connect-client-app/node_modules/mocha/lib/runnable.js:259:7)
    at next (/Users/rod/Documents/GitHub/ripple-connect-client-app/node_modules/mocha/lib/runner.js:271:10)
    at Object._onImmediate (/Users/rod/Documents/GitHub/ripple-connect-client-app/node_modules/mocha/lib/runner.js:292:5)
    at processImmediate [as _immediateCallback] (timers.js:345:15)

NuclearTestUtils.js:32:36 is the reactor.get().

Looking at logs, this seems to happen when an Immutable Record (a Getter) is passed as an argument into the anonymous function whose return value is assigned to isArray on line 6848. When you try to get the length of the Immutable Record, the error on line 1627 gets thrown.

Really love the ideas behind nuclear-js!

Are there any ambitions to create separate modules of this concept to allow it to be easily
used in a standard flux concept (by creating more generic parts out of nuclear....)?

When I understand it correctly, the parts of nuclear do not differ too
much from common flux patterns...

For a framework that enforces a data model composed of immutable data, would it not make sense to enforce immutability for the event payloads?

A common pattern, when updating a store, is to set or deeply merge the event payload into the Immutable.Map or Immutable.List representing the store state. It's error-prone to always have to manually convert the payload to an immutable object - I can see no use-case for ever dispatching a mutable event payload.

Proposal: In flux.dispatch(...), always perform Immutable.fromJS(...) for a non-null payload.

I'm happy to add this and send a pull request, this is just a request to see if anybody else feels this way?

I'm having a bit of trouble developing a pattern to handle getters with a dependency on some app state that may be null. See the getters bellow:

// getters.js
exports.org = ['org'];
exports.menus = ['menus'];
exports.selectedMenu = [exports.org, exports.menus, (org, menus) =>
  menus.find(menu => menu.get('id') === org.get('default_menu'))
];

If org and menus are both defined, this is fine. But it may be possible for them to be undefined, which would cause a .get() of undefined.

I know I can code defensively in computed properties to return a reasonable value if they are undefined but this feels like a bad pattern to adapt everywhere.

I believe part of the problem I'm having is that when getDataBindings returns an object (like below) it 'pulls' on the computed properties attempting to get a value

// menu.jsx - requires the getters.js
module.exports = React.createClass({
  mixins: [flux.ReactMixin],

  getDataBindings: function() {
    return {
      menus: Session.getters.menus,
      selectedMenu: Session.getters.selectedMenu,
    };
  },

  render() { ... }
});

I'm assuming that you have a pattern to avoid loading the menu.jsx component if the data required for it hasn't been populated yet? Do you just return false in the parent component's render() if the data isn't there? Am I making any sense?

Hi @jordangarcia

I'm currently learning React and the Flux architecture and came to your library when researching how to use Stores with Immutables. I've stumbled upon a couple of problems / questions though when applying it to my example, so let me explain a bit what I did.

In my example I want to fetch some data from an API when the component is rendered. In the ideal scenario with a Flux architecture it would look like this:

• Component will render
• Component asks state from Store
• Store provides default state to component and triggers an Action to fetch data from an API
• Component renders with initial state
• Action creator execute async request using some util library
• Action creator processes request and if successful will dispatch payload
• Store handles dispatched payload and updates its (immutable) state
• Store informs Component that it has a new state
• Component rerender with new state

Now, when I implement this flow using the Reactor the last step is not executed, which could be the same problem @ArnoBuschmann is having #4

...with checked-in node_modules, which seem to break react-native. It's react native's fault that they are getting tripped up on an example folder, but I thought you might want to make sure that the latest nuclear-js is up on NPM.

@jordangarcia - We should decide on a license to use for this open source repository.

Based on: http://choosealicense.com/, I would lean towards MIT. Thoughts?

Running grunt test on master currently results in an error complaining about missing grunt/karma-configs/phantom.karma.js, which indeed it is having been removed in 247dcac. I'm guessing this was inadvertent and the fix might be as simple as adding it back in? If so, I'm glad to open a PR. I figured I'd check though in case this was part of an intentional move away from using Phantom.

Would it make sense to allow a reactor instance's change observer to remove a handler? I think that would be a bit cleaner than saving reference to the observer's unwatch function and calling that at some point

Many of the tools in the React ecosystem have a real-time chat room for their users (and perhaps developers) to discuss best practices and plan for future versions. Gitter is a nice way to provide this, because it's hosted and well-integrated with GitHub.

@jordangarcia should be able to create a room by following this link.

Hi again,

Just checked out the next-update-readme-example branch and very impressed with all the progress you guys are making, on docs and code.

One thing that seems to be missing is examples around interacting with a REST API for fetching/syncing/saving data. I imagine it'd be fairly straightforward, especially along the lines of a "Web API Utils" idea... but if you guys have patterns that work it might be nice to share them so devs know what to expect & how to architect.

My assumed pattern:

// web-api.js

reactor.observe("user", updatedUser => _saveUserToServer(updatedUser));

socket.on("message", (message) => {
  if (message.type === "user") {
    reactor.dispatch("user.update", message.user)
  }
})

function _saveUserToServer(user) {
  reactor.dispatch("user.request", user);
  xhrStuff(url, user).then(resp => {
    reactor.dispatch("user.sync", resp.user)
  }).error(e => reactor.dispatch("user.error", e))
}

One thing I love about Backbone (and the reason I sometimes use it with Flux/React) is that it takes care of all this stuff for you, including tracking when an item is syncing, synced, invalid, or in an error state. It's also incredibly convenient to just set a "url" attribute and then call .save(). I'm not sure if it makes sense to incorporate all of that into Nuclear, but an example showing it off might be worthwhile.

What is the correct way to load deeply nested data using NuclearJS? The chat example shows a basic parent/child relationship where the children are wholly contained within the parent, but in my case the parent and child are related via references. Given that, I'm not sure what the most pragmatic way to load additional levels of data would be (especially since these deeper levels may still need to be fetched from the server if they aren't in a store).

Here is an example of the data in my store:

{
    tasks: {
        1:  {id: 1, name: 'task1', contacts: [{id: 1}], files: [ {id: 1}, {id: 2}]},
        2:  {id: 2, name: 'task2', files: [ {id: 1}, {id: 4}]},
    },
    files: {
        1:  {id: 1, name: 'file1', contacts: [ {id: 1}, {id: 2}]},
        2:  {id: 2, name: 'file2', contacts: [ {id: 1}]},
    },
   contacts: {
        1:  {id: 1, name: 'contact1'},
    }
}      

Currently I have a current-task-id-store that tracks the currently selected task. I can then use this state to grab the files for the task.

// current task id store
function setCurrentTaskID(state, { taskID}) {
  // return the new value of the store's state
  return taskID
}

// task getters
exports.currentTask = [
  ['currentTaskID'],
  exports.tasksMap,
  (currentTaskID, tasksMap) => tasksMap.get(currentTaskID)
]

exports.currentTaskFiles = [
  exports.currentTask,
  ['filesMap']
  (currentTask, filesMap) => ...get files from store / dispatch fetch from server...
]

I then use getDataBindings to get the set of files that I need to render.

// fileSection component
var FileSection = React.createClass({
  mixins: [reactor.ReactMixin],

  getDataBindings() {
    return {
      files: Task.getters.currentTaskFiles
    }
  }, ...

However, now I need to load the contact references for each of those files so that I can render them. I'm not sure how to write a functional getter that would load/fetch them. I thought about just using a binding to get the contactsMap and looking up the values directly but this doesn't seem right and doesn't work in cases where the contact needs to be fetched from the server.

There's mention of eventually providing documentation around structuring large nuclear apps using modules, but since that's not provided yet, I was hoping to get some insight on the recommended convention.

I've taken a look at Tetris, and see where things are going, but it would be awesome to know more about when/why to use modules and any other org details.