-
Notifications
You must be signed in to change notification settings - Fork 407
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
What is the plan for moving to ES6? #38
Comments
No plans at the moment, although I'd gladly comment on any PRs you send my way. We've been discussing how to get Firebase working with React Native and I think this also ties into that a little bit. Do you have any concrete ideas here? |
Great to learn about the discussion on Firebase and RN integration! In terms of component development I'm just looking for the optimal way for Firebase to provide the data and then for editing that data on a component, in light of the rapid progress being made with ES6 and React. There are a number of proposals out there (the ones I mentioned) and I'm considering them in the context of the app I'm engineering. I have an app with more than just a couple gears to it so it provides the dynamic to work with, I'll be in touch with what I resolve. |
Hi, any development on how to use in ES6? |
There are still no active plans to update ReactFire for ES6 / React Native. You may want to check out re-base (https://github.com/tylermcginnis/re-base) which may fulfill your needs. |
+1 |
3 similar comments
+1 |
+1 |
+1 |
The React team chose not to allow the existing mix-in pattern when creating a React component the ES6 way because JS doesn't currently have a standard method for doing mix-ins. So The nice thing is you can mix both ES6 class and |
There are new frameworks like Cycle.js than need a Firebase driver too. The driver is their specific way of adding a service to Cycle.js. IDEA! Instead of Firebase always making a specific package per given framework why not create a core dropin service and then a set of plugins for specific things like Relay, Falcor, etc. Actually, Relay and Falcor are less robust copycats of Firebase any ways and the core aspects of Firebase should remain the main focus. Surely, it is not the best to always have to completely customize per framework. Would it not be better for Firebase to instead provide a ES6 module with the essential core features available as higher order functions and then provide plugins for the rest? This could always be done using the existing Firebase API but there is still a lot of re-inventing the wheel per project that way. To me Firebase stands on its own as a global service to XYZ framework components and the bridge into the specific component architecture of a given framework should be as thin as possible. It is to be expected that any savvy framework can work with ES6 modules and a library of higher order functions. While a framework may come and go Firebase does not! |
Not a bad idea @HighOnDrive. I know you'd really like to see a Cycle.js driver, but we just don't have the resources right now to investigate and develop one. We'd love to see something come out of the community though! As for your idea about creating an ES6 module with core features, I think that is compelling. For example, it certainly would be nice to not have to recreate the realtime array logic for every new binding. However, with our core product, we need to be more cautious for many reasons: a lot more people use it, a lot more people abuse it, and we support a lot of legacy browsers. With things like ReactFire, we can be more aggressive, dropping support for old browsers and providing APIs which people may (unintentionally) abuse. It's a tough line to tread and in order for us to move it into the core SDK, we need to be very sure of it. I appreciate the discussion here and I hope it continues. I'd love to hear more about your ideas here! |
resources can be solved by hiring :-) |
Parse maintains a similar mixin for connecting to React, but also provides a method for using ES6 classes for use with observables a la RxJS and the related React proposal. Is that something which seems worthwhile? Regardless users can still leverage REST and Flux, and leverage the new Firebase CLI tools for Node while building. |
I had a little go at designing a fresh firebase API as a higher order component. This is what I came up with. const ref = new FirebaseEndpoint('https://myapp.firebaseio.com');
@connectFirebase((props) => {
return { // this allows us to reconfigure when out targets props change
// if needed this could also prolly return a promise
endpoint: ref, // should allow passing this via this.context too
keys: {
user: '/users/$userid',
messages: `/rooms/${props.roomId}/messages`,
},
paths: {
'/users/$userid': null,
`/rooms/${props.roomId}/messages`: {
isArray: true,
query: {
limitToLast: 10,
},
},
},
};
}, (keys, states, actions) => {
return { // this object becomes assigned to the wrapped components props
// we can also require more complicated actions and state reducers here and mix them in in more complex apps
user: states[keys.user],
messages: states[keys.messages],
updateUser: ({name}) => actions[keys.user].set({name}), // firebase will automatically trigger a change even right away and keep the props update
};
})
class App extends Component {
render() {
const {updateUser, user} = this.props;
return (
<div>
Hi <input value={user.firstname} onChange={(evt) => updateUser(evt.target.value)} type="text"/>
</div>
);
}
} |
We need a RxJS module for Firebase that is not tied into any specific framework. The same module could then work with all the frameworks that have already moved to RxJS. When is Firebase going to quit sitting on their asses about this and get with the program!? I mean it's a new day now with FRP in the picture, just check out what happened at the Reactive 2015 conference or the RxJS videos being presented from Angular2 events, etc, etc. etc, etc. Cycle.js also made a real dent in the universe at Reactive 2015, here is an article in case anyone wants a jump start on the future: https://medium.com/@fkrautwald/plug-and-play-all-your-observable-streams-with-cycle-js-e543fc287872 |
👍 GraphQL & RxJS would be awesome! |
It can help to mixin into react es6 component https://github.com/brigand/react-mixin import React, { Component } from 'react'
import Firebase from 'firebase'
import ReactFireMixin from 'reactfire'
import reactMixin from 'react-mixin'
const ref = new Firebase('https://<APPNAME>.firebaseio.com/users')
class UsersList extends Component {
constructor (props, context) {
super(props, context)
this.state = {
users: []
}
}
componentDidMount () {
this.bindAsArray(ref, 'users')
}
renderUser (user) {
return <p>{user.name}</p>
}
render () {
return (
<div>
{this.state.languages.map(this.renderLanguage)}
</div>
)
}
}
reactMixin(UsersList.prototype, ReactFireMixin)
export default UsersList I created gist. You can fork it here: https://gist.github.com/kulakowka/24bb83775358ad4c3bc7 |
|
ES6 is dead. Long live COBOL! |
Jacob's answer continues to be the latest and greatest. Posts adding value on how devs can get up to speed on ES 6 or working toward a PR are welcome. Posts asking for release dates or discussing other features will be pruned. Please keep discussion on topic and productive. |
Hello Here is a proposal for a PR. import { Component } from 'react';
import reactFire from 'reactfire';
class MyComponent extends Component {
}
export default reactFire(MyComponent);
//OR ES7 decorator style
@reactFire()
export default class MyComponent extends Component {
} |
So here is a first shot at it There is an API breaking change, since it's using a high order component, everything happens in your component's props. |
@fdidron I love the decorator idea. With many devs using Babel this could be a nice syntactic gain that still achieves the same idea as the mixin. |
I think A component is way overcomplicating the API. It should just be a single call to attach methods to the class or instance, or just static methods on the class User extends React.Component {
constructor (props) {
fPosition = props.fPlayer.child("position")
fContacts = props.fPlayer.child("contacts")
ReactFire.bindAsObject(this, "position", fPosition)
ReactFire.bindAsArray(this, "contacts", fContacts)
}
render () {
{contacts, position} = state
{x, y} = position
<div class="user" style={left: x, top: y}>
<Contacts contacts={contacts}/>
</div>
}
} (Those methods could do some initialization the first time something is binded, and overload the |
@1j01 That requires any object that wants to use Firebase to be a class, so you can't use it with function components. I still think a container is the most flexible option. Anything where you still need to manage binding/unbinding requires keeping state, which I think you should avoid as much as possible. |
@bigblind Okay, well I didn't consider function components (I've never used them) |
I just spent 3 hours writing an elaborate answer to this question only then to accidentally open another page in that tab... 😭 Here's the gist of it:
I might update this post with more useful links when I'm less depressed about browsers not saving draft form responses... 3 hours... wasted. |
@bigblind What browser are you using? Chrome seems pretty good about saving things, navigating forwards, backwards, closing and reopening tabs. Not that I haven't lost plenty of stuff to Chrome. Anyways, seems like a reasonable approach. |
Hey, what's the current status of this conversation? |
I actually finally found some time this past weekend to test out a new HOC API myself. I am hoping to have a proposal in PR form soon. I'm leaning towards going with an API similar to what @bigblind suggested, but there are still a few performance concerns that need to be figured out (mainly around re-binding Firebase listeners upon changes to props). |
@jwngr That is awesome to hear! Excited to check it out. |
@jwngr Sweet, I will be eagerly waiting! @prescottprue love your v3 lib on firebase redux! That's what's keeping me a float currently. |
Thanks @birdwell, that is exactly what it is for! For those who haven't seen it: redux-firebasev3 was made as a way to get v3 implemented in React/Redux. I figure that ReactFire will take its place eventually, but I needed a solution before then. |
Same with re-base, there's a PR awaiting merge which adds v3 support: tylermcginnis/re-base#104 |
Here's a completely different approach I've been experimenting with: I'm bypassing ReactFire altogether, and instead made two APIs:
Example usage: import React from 'react'
import { observeValue, observeCurrentUser } from './firebase-observable'
import connectObserver from './connect-observer'
export default connectObserver({
// function takes props and returns an Observable or Promise
post: ({ postId }) => observeValue(firebase.database().ref('/posts').child(postId)),
user: () => observeCurrentUser(firebase.auth())
})(class Post extends React.Component
static propTypes = {
postId: React.PropTypes.string.isRequired,
post: React.PropTypes.shape({ … }),
user: React.PropTypes.object
};
render () {
const { post, user } = this.props
return …
}
})) |
Do the owners of the reactfire repo have a recommended approach, or stated plans for using reactfire w/out mixins? |
@hyperbrave - #38 (comment) is still the latest. I really want to get this out but I haven't found the time to finish my proposal yet. |
Hi! |
Wow, time marches on and life improves! Just saw this issue popup again and wanted to say that I did find a awesome solution that is built on RxJS. You may of heard of it by now, it’s called RethinkDB Horizon, see link below for more:
|
How about TypeScript ? |
In case it helps, this simple HOC works, even if there is better solution. import ReactFireMixin from 'reactfire';
const ReactFire = ParentComponent => class extends ParentComponent {
static displayName = 'ReactFire' + (ParentComponent.displayName || 'ExtendedComponent');
constructor(props) {
super(props);
// properties should be:
// componentWillMount, componentWillUnmount, bindAsArray, bindAsObject, unbind
for (var property in ReactFireMixin) {
if (ReactFireMixin.hasOwnProperty(property)) {
let value = ReactFireMixin[property];
if (property in this) {
let method = this[property].bind(this);
let rfMethod = ReactFireMixin[property].bind(this);
value = (function(...args) {
method(...args);
rfMethod(...args);
});
}
Object.defineProperty(this, property, {value: value.bind(this)});
}
}
}
};
export default ReactFire; |
I dont understand why there is no good solution for this? |
With respect to the pending HOC API and performance issues when props change, I suspect the concern is that (a) refs are equivalent even though there's been a props change, and (b) we don't want to incur the overhead of unbinding and rebinding to an equivalent ref. Basically, we just need some way to check Firebase refs for "equality", right? That is, is there some way to do the following?
If there was, it'd make it trivial to handle the binding/rebinding performance concerns. We'd check if two refs are equivalent, and if they are, don't rebind. Alternatively, the HOC API could require that users provide some sort of key string for each ref to help with comparison (this would be distinct from the state key we're binding to -- this key would have to change if and only if the ref changed). But this seems like something that should handled in the Firebase library itself, not in ReactFire. |
For anyone that is still looking for a solution to this, you might want to checkout It provides a HOC similar to those proposed above. |
React Fire seems dead, is it? |
I've switched to https://github.com/unfold/react-firebase |
We have officially deprecated reactfire, as we no longer believe it is the best solution for Firebase developers looking to integrate with React. Please see the |
React is phasing out mixins with the change to ES6 classes. What is the plan for the reactfire mixin with this coming change? Could reactfire also tie in with react contexts? Below is a link to the context approach:
https://blog.jscrambler.com/react-js-communication-between-components-with-contexts
React relay with graphql is another approach coming to react. It would seem like reactfire updated to work with ES6 classes and the context approach might be a powerful alternative to relay with added collaboration! It might also work to incorporate some of the graphql as well?
The text was updated successfully, but these errors were encountered: