Comments (17)
@mindjuice could you please elaborate on a this-less style? You can easily use React.createClass()
instead of class NuclearComponent extends React.Component {}
, as that's just an implementation detail.
How is
var MyComponent = React.createClass({
// ...
})
MyComponent = nuclearComponent(MyComponent, dataBindings, reactor)
less 'this-less' than
var MyComponent = React.createClass({
mixins : [ flux.ReactMixin ]
// ...
})
I think it's nicer, if you don't force others to use a certain feature if it's not necessary. To reduce code duplication, you could even use the mixin internally:
function nuclearComponent(Component, dataBindings, reactor) {
return React.createClass({
mixins : [ flux.ReactMixin ],
getDataBindings() { return dataBindings; }
render () { return <Component {...this.props} {...this.state} /> }
}
})
from nuclear-js.
Turns out there was some misunderstanding on this. Mixins are not going anywhere (at least not soon). The React Router guys reverted their code back to mixins.
https://github.com/rackt/react-router/blob/master/UPGRADE_GUIDE.md
I prefer to avoid ES6 classes for as long as possible (hopefully forever). I would prefer a ''this-less" style for React.
from nuclear-js.
Programming JS without this
basically involves using functions to create "objects" out of closures, as is often done in other functional languages like Scheme. You get clean, simple access to your data by name only without worrying about what object this
points to at any given time (since there isn't a this
). The tradeoff is "objects" usually take more space.
Anyway, I generally avoid this
, classes and inheritance in my non-React code.
Of course, with React I don't get to avoid this
, but they made it nicer by ensuring that this
is properly bound for all functions and event handlers. You still have issues when using things like _.map()
and the like where you resort to the var that = this;
ugliness.
My comment was just wishful thinking that React would move to a "thisless" style. It's something that they have thought about based on comments I've see before. Also, there is this "declarative" experiment to create a React component in the react-future repo.
I don't follow your comment about forcing others to use a certain feature. Which feature is being forced onto others?
from nuclear-js.
By only providing a mixin, as a consumer of Nuclear I'm forced to write the components in a certain way. I understand, that this is sometimes necessary when choosing your tools / libraries.
You can use the decorators under all circumstances, while mixins are only working with React.createClass()
.
from nuclear-js.
I see. Yes, it would be nice if it worked regardless of which way you chose to structure your objects.
Decorators would require ES6 though, so perhaps it could provide both mixins and decorators.
from nuclear-js.
It'd require ES7 even, if you really want to use the @decorator
syntax. But that's only syntactic sugar, which is nice. The functions themselves are backwards compatible, even with ES5. You just call the function with the object you want to decorate as the first argument.
MyComponent = decorator(MyComponent)
I'd definitely be willing to contribute a PR if there's interest in this.
With the approach outlined above it'd result in that the requested bindings are no longer available on this.state
, but on this.props
of the decorated component and I'm not certain on whether that's a good thing or not. On the one hand, it changes the API and decorated components would work differently to the components using the mixin. On the other hand, it also makes the decorated component more reusable and decoupled from Nuclear, which might be a good thing.
from nuclear-js.
I will definitely investigate this more, as its my goal to have first class support for use of with React out of the box.
However I imagine there are ways to use a Nuclear Reactor to create some sort of NuclearComponent
class with the current library, much like @ksmth shows in the example code.
The following statement is from the React v0.13.0 Beta 1 blog post
Therefore, we will keep working with the larger JS community to create a standard for mixins. We will also start designing a new compositional API that will help make common tasks easier to do without mixins. E.g. first-class subscriptions to any kind of Flux store.
If React adopts a good solution support a more compositional paradigm I believe that would suit Nuclear's functional style.
Until then it seems fine for people to create their own NuclearComponent
class that has the same functionality of the mixin.
@ksmth if you are interested in PRing an example of using this style of NuclearComponent class I would be happy to merge and link from the README as the prescribed way of using NuclearJS with React ES6 classes.
from nuclear-js.
I'm with @ksmth on this one. While mixins are still the idomatic way of sharing code across React components, it's pretty clear that they're not ideal. It seems to me that the React team is waiting to see what patterns emerge in the community, and I think Nuclear should be making an effort towards contributing to that.
I'm not suggesting replacing flux.ReactMixin, but instead proving a second/alternative baked-in manner for sharing store binding logic.
I see a few benefits to using a higher order function instead of a mixin:
1 - Leans on composition over inheritance
2 - Removes state from presentational components
3 - Allows data fetching components to make sure that all the data required to render a presentational component exists before that component's render function is called (no more if (!this.state.someVal) return null
)
4 - Makes it much clearer when a particular lifestyle hook is invoked on a component, because they're all only ever declared within it's class declaration
It seems to me that Relay Components are pushing for this sort of pattern, and I think we can substitute graphql with Nuclear getters to achieve something similar.
I like a slightly modified API to what @ksmth first wrote. The difference being, I think you can safely rely on the factory living off of the reactor, and I wouldn't pass state down into child components.
class MyComponent extends React.Component {
render() {
return <div>{this.props.someValue}</div>
}
}
export default flux.Component(MyComponent, {
someValue: SomeFluxModule.Getters.someValue
})
A possible, more JSX derived, alternative might look like this:
import {NuclearComponent} from 'nuclear-js'
import SomeFluxModule from './some-flux-module'
const dataBindings = {
someValue: SomeFluxModule.Getters.someValue
}
class MyComponent extends React.Component {
render() {
return (
<NuclearComponent dataBindings={dataBindings}>
<MyChildComponent />
</NuclearComponent>
)
}
}
class MyChildComponent extends React.Component {
render() {
return <div>{this.props.someValue}</div>
}
}
I strongly encourage more debate on introducing a non-mixin-based way to get Nuclear store data into a component.
from nuclear-js.
fwiw I find a standardized NuclearComponent to be pretty interesting, for many of the reasons listed above. Mixin's certainly shouldn't go anywhere though.
Hopefully once a few members of the community have built & used their own for a bit we can get a PR. I may try this myself.
from nuclear-js.
One problem with JSX components is they will only work on a particular platform. We'd have to have separate components for DOM, iOS, Android, etc etc. Not to mention other frameworks!
from nuclear-js.
Don't think that's necessarily true. JSX isn't a templating language like we're used to (handlebars, lodash, etc), because it isn't meant to build up HTML; it's a declarative syntax for building up virtual DOM. That reason is exactly why it can be used to create native iOS UI elements, android elements, and even arbitrary trees representing anything you'd like.
Getting a component to work against multiple platforms would/should be an implementation detail in my opinion.
from nuclear-js.
I definitely agree with having a HoC/decorator/wrapper.
from nuclear-js.
Having an alternative to Mixins would be great!
from nuclear-js.
https://github.com/jordangarcia/nuclear-js-react-addons should suit your needs.
Let us know what you think.
from nuclear-js.
Looks awesome @Sinewyk @jordangarcia. Really like that it supports decorators too
from nuclear-js.
Glad I came across this after it was solved :).
from nuclear-js.
Closing this as it can be found here: https://github.com/jordangarcia/nuclear-js-react-addons
from nuclear-js.
Related Issues (20)
- Is it possible to use ReactMixin with ECMA6 class extension syntax? HOT 3
- Data Bindings as Props instead of State HOT 3
- [HELP]NuclearJS + Babel 6 as transpiler HOT 3
- Nuclear Module HOT 4
- [Question] How do dispatch one action within another action? HOT 2
- [Question] Data store dependency HOT 3
- Getter dependencies not being cached HOT 15
- ImmutableJS dependency HOT 7
- [HELP] NuclearJs reports "TypeError: Cannot read property 'dispatch' of undefined" HOT 5
- Logging fails on older Android browsers when called with `null` or `undefined` HOT 3
- Upgrade Immutable to the latest version HOT 2
- When using batch, do not receive error when calling dispatch inside of dispatch HOT 2
- reactor.dispatch throwing error 'VM31785:6061 Uncaught Error: `dispatch` cannot be called with an `undefined` action type.' HOT 1
- ES6 Support HOT 1
- Is this project still being maintained? HOT 3
- Disable Dispatch logs using debug packages HOT 3
- Observer not called HOT 2
- Active? HOT 2
- Github Project Template Files
- Online documentation is out of date vs source documentation
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from nuclear-js.