You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[](https://gitter.im/optimizely/nuclear-js?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge)
6
-
7
6
[](https://saucelabs.com/u/nuclearjs)
8
7
9
8
Traditional Flux architecture built with ImmutableJS data structures.
@@ -14,47 +13,47 @@ Traditional Flux architecture built with ImmutableJS data structures.
14
13
15
14
## Design Philosophy
16
15
17
-
-**Simple over Easy** - The purpose of NuclearJS isn't to write the most expressive TodoMVC anyone's ever seen. The goal of NuclearJS is to provide a way to model data that is easy to reason about and decouple at very large scale.
16
+
-**Simple Over Easy** - The purpose of NuclearJS isn't to write the most expressive TodoMVC anyone's ever seen. The goal of NuclearJS is to provide a way to model data that is easy to read and decouple at very large scale.
18
17
19
-
-**Immutable** - A means for less defensive programming, more predictability and better performance
18
+
-**Immutable** - A means for less defensive programming, more predictability and better performance.
20
19
21
20
-**Functional** - The framework should be implemented functionally wherever appropriate. This reduces incidental complexity and pairs well with Immutability.
22
21
23
-
-**Smallest Amount of State Possible** - Using Nuclear should encourage the modelling of your application state in the most minimal way possible.
22
+
-**Smallest Amount of State Possible** - Using NuclearJS should encourage the modeling of your application state in the most minimal way possible.
24
23
25
24
-**Decoupled** - A NuclearJS system should be able to function without any sort of UI or frontend. It should be backend/frontend agnostic and be able to run on a NodeJS server.
26
25
27
26
## Installation
28
27
29
-
NuclearJS can be downloaded from npm.
28
+
NuclearJS can be downloaded from [npm](https://www.npmjs.com/).
30
29
31
30
```
32
31
npm install nuclear-js
33
32
```
34
33
35
34
## Examples
36
35
37
-
-[Shopping Cart Example](./examples/shopping-cart) general overview of NuclearJS concepts: actions, stores and getters with ReactJS.
38
-
-[Flux Chat Example](./examples/flux-chat) classic facebook flux chat example written in NuclearJS.
39
-
-[Rest API Example](./examples/rest-api)shows how to deal with fetching data from an API using NuclearJS conventions.
36
+
-[Shopping Cart Example](./examples/shopping-cart)- Provides a general overview of basic NuclearJS concepts: actions, stores and getters with ReactJS.
37
+
-[Flux Chat Example](./examples/flux-chat)- A classic Facebook flux chat example written in NuclearJS.
38
+
-[Rest API Example](./examples/rest-api)- Shows how to deal with fetching data from an API using NuclearJS conventions.
40
39
41
40
## How NuclearJS differs from other Flux implementations
42
41
43
42
1. All app state is in a singular immutable map, think Om. In development you can see your entire application state at every point in time thanks to awesome debugging tools built into NuclearJS.
44
43
45
44
2. State is not spread out through stores, instead stores are a declarative way of describing some top-level domain of your app state. For each key in the app state map a store declares the initial state of that key and how that piece of the app state reacts over time to actions dispatched on the flux system.
46
45
47
-
3. Stores are not reference-able nor have any `getX` methods on them. Instead Nuclear uses a functional lens concept called **getters**. In fact, the use of getters obviates the need for any store to know about another store, eliminating the confusing `store.waitsFor` method found in other flux implementations.
46
+
3. Stores are not reference-able nor have any `getX` methods on them. Instead NuclearJS uses a functional lens concept called **getters**. In fact, the use of getters obviates the need for any store to know about another store, eliminating the confusing `store.waitsFor` method found in other flux implementations.
48
47
49
-
4. NuclearJS is insanely efficient - change detection granularity is infinitesimal, you can even observe computed state where several pieces of the state map are combined together and run through a transform function. Nuclear is smart enough to know when the value of any computed changes and only call its observer if and only if its value changed in a way that is orders of magnitude more efficient than traditional dirty checking. It does this by leveraging ImmutableJS data structure and using a `state1 !== state2` reference comparison which runs in constant time.
48
+
4. NuclearJS is insanely efficient - change detection granularity is infinitesimal, you can even observe computed state where several pieces of the state map are combined together and run through a transform function. NuclearJS is smart enough to know when the value of any computed changes and only call its observer if and only if its value changed in a way that is orders of magnitude more efficient than traditional dirty checking. It does this by leveraging ImmutableJS data structure and using a `state1 !== state2` reference comparison which runs in constant time.
50
49
51
50
5. Automatic data observation / rendering -- automatic re-rendering is built in for React in the form of a very lightweight mixin. It is also easily possible to build the same functionality for any UI framework such as VueJS, AngularJS and even Backbone.
52
51
53
52
6. NuclearJS is not a side-project, it's used as the default Flux implementation that powers all of Optimizely. It is well tested and will continue to be maintained for the foreseeable future. Our current codebase has over dozens of stores, actions and getters, we even share our prescribed method of large scale code organization and testing strategies.
54
53
55
54
## Performance
56
55
57
-
Getters are only calculated whenever their dependencies change. So if the dependency is a keypath then it will only recalculate when that path in the app state map has changed (which can be done as a simple `state.getIn(keyPath) !== oldState.getIn(keyPath)` which is an `O(log32(n))` operation. The other case is when a getter is dependent on other getters. Since every getter is a pure function, Nuclear will only recompute the getter if the values if its dependencies change.
56
+
Getters are only calculated whenever their dependencies change. So if the dependency is a keypath then it will only recalculate when that path in the app state map has changed (which can be done as a simple `state.getIn(keyPath) !== oldState.getIn(keyPath)` which is an `O(log32(n))` operation. The other case is when a getter is dependent on other getters. Since every getter is a pure function, NuclearJS will only recompute the getter if the values if its dependencies change.
58
57
59
58
You can read more of the implementation here: [src/evaluator.js](./src/evaluator.js)
60
59
@@ -64,7 +63,7 @@ You can read more of the implementation here: [src/evaluator.js](./src/evaluator
64
63
65
64
## For Smaller Applications
66
65
67
-
NuclearJS was designed first and foremore for large scale production codebases. For a much more lightweight Flux implementation that shares many of the same ideas and design principles check out [Microcosm](https://github.com/vigetlabs/microcosm).
66
+
NuclearJS was designed first and foremost for large scale production codebases. For a much more lightweight Flux implementation that shares many of the same ideas and design principles check out [Microcosm](https://github.com/vigetlabs/microcosm).
0 commit comments