polymerfire
polymerfire copied to clipboard
FirebaseExtended
Direction of Polymerfire
@merlinnot We can put our discussion here.
Because of the dependencies included in Polymerfire, I don't know if it would be possible to port it out on its own without the need of using the Polymer's local storage. It would be nice but I am thinking of doing a do-over of the whole thing with the thought of making it into a standalone web component without dependency on Polymer (which makes it big).
That would make it a breaking change though and will not be compatible to either Polymer 1 or 2 (or actually we can still make it compatible by making just an html to load the js file.
We need to do an inventory of the tests, and the other tests as well so we can just add on top of it.
Ok, if we drop Polymer, should we still call it Polymerfire? ;)
On a more serious note: What would be the purpose of these components in this scenario? For Firestore mixin it might actually work, since it’s a mixin, we can set properties on an instance and people can use PropertiesMixin to subscribe to these changes (would work with both Polymer 3 and Lit). What about database etc.? What’s your idea? How can we make the experience better than just using the SDK?
One of the things that people requested a lot is making it more declarative, which isn’t really a direction which is now recommended and which people take with new apps.
To be frank, it would be more valuable if the Polymerfire components did more than simply wrap the existing javascript library. There's not much value there. What would be of value however, would be a series of components that leverage the Firebase javascript library to do common tasks:
- A file upload component that lets you drag and drop a file into storage with a similar look and feel to what you get in Google Drive.
- An aesthetically pleasing login component that lets you select auth providers.
- An infinite scrolling card tray with support for caching in local storage.
- A filterable card tray with support for pluggable filters and filter dialogs
- A pageable table/grid component
- An autocomplete component that works with a user-definable query.
- An auth component with support for setting/getting custom claims.
- An editable listbox component that lets you update the database with new values.
- A mixin that makes it easy to use custom auth credentials so that developers can easily implement role-based components.
- Versions of the components that can be used either with the realtime database, or with Firestore.
A firebase starter kit template (similar to the Polymer Starter Kit) that demonstrates best practices.
Admittedly, most of the these components are not difficult to implement, but when you're just getting started with Firebase, it would be nice to have a set of components that cuts down on the amount of work you have to do to get an application up and running.
I guess I think it would be apt to start again with the basics:
- firebase scripts
- firebase behaviors (backwards compat) / mixins (for polymer 3)
- general mixin
- auth
- database
- storage
- firestore
- basic declarative components of the mixins
- firebase-auth
- firebase-query
- firebase-document
- firebase-storage
- firestore-query
- firestore-document
- and then the ones @phidias51 suggested
And then create a Firebase starter kit template
Could you give me an example of how you imagine firestore-query? I'm trying to think of something that would really improve user experience, but I have trouble finding a good example.
Do you want it to look like this?
class MyFavoriteEmoji extends LitElement {
static get properties() {
return {
emoji: String,
uid: String,
};
}
_render({ emoji, uid }) {
return html`
<firestore-document
path="users/${uid}"
on-change="${({value: {after: {favEmo}}}) => this.emoji = favEmo}">
<div>${emoji}</div>
`;
}
}
Right... I forgot that there's no double binding with polymer 3 (or at least that's what it seems when using lit-html).
Making it declarative, I would be thinking
_render() {
return html`
<firestore-document
path="users/${uid}"
on-change=${this.changeEmoji.bind(this)}></firestore-document>
`
}
changeEmoji ({value}) {
this.emoji = value
}
Ughhh... welp this makes it a little bit harder if it becomes declarative without double binding.
That's why I'm asking. It's really fun and easy to use the firebase-js-sdk with things like redux-saga or RxJS. The only thing I can imagine would be really helpful is wrapping (which is a fairly easy thing to do) firebaseui-web, so one could consume it as a component.
Mixins might be ok-ish too, both for Firestore and Realtime Database.
File upload with drag & drop? I could actually share the one that I wrote for myself, it's of a high quality.
But these changes would dramatically change this repository, it wouldn't be even slightly similar to what we have now.
I think as long as we can have the original components, we can still use it. The double binding might still work as long as we get to keep the original event firing mechanisms when properties changes.
As for the other stuff, I think if the community needs it, it should be provided.... as long as we don't get our selves into doing a scope creep.
Compatible in such a way that they can still do this:
<firebase-query data="{{data}}"></firebase-query>
Which I think should work if we have this.dispatchEvent(new CustomEvent('on-data-change', { detail: data }));
Web components are a set of web platform APIs: Custom Elements, HTML Templates, Shadow DOM, HTML Imports (ES Modules / HTML Modules). The component does not have to use all of these specifications. If the web component does not use HTML Templates, Shadow DOM, HTML Imports (ES Modules / HTML Modules) specifications, it is still a web component. But what if the web component does not use Custom Elements specification? Is it still a web component? What if it does not use any of these specification? Is it still a web component?
Custom Elements is what makes web components declarative.
The best thing of web components is that they are interoperable, they can be used in a Polymer project, despite the fact that they themselves are written using lit-element.
Imagine that <firebase-document> web component (custom element) is written using lit-element.
If I use <firebase-document> web component in <my-view> that written using Polymer template system (that supports two-way data binding):
import {PolymerElement, html} from '@polymer/polymer/polymer-element.js';
import '@polymer/polymerfire/firebase-document.js';
class MyView extends PolymerElement {
static get properties() {
return {
data: {
type: String
}
}
}
static get template() {
return html`
<paper-input value="{{data}}"></paper-input>
<firebase-document
path="/note/text"
data="{{data}}">
</firebase-document>
`;
}
}
customElements.define('my-view', MyView);
If I use <firebase-document> web component in <my-view> that written using lit-element (there is no two-way data binding in lit-element):
import {LitElement, html} from '@polymer/lit-element/lit-element.js';
import '@polymer/polymerfire/firebase-document.js';
export class MyView extends LitElement {
static get properties() {
return {
data: String
}
}
_render({data}) {
return html`
<paper-input on-value-changed="${(e) => this.data = e.detail.value}"></paper-input>
<firebase-document
path="/note/text"
data="${data}"
on-data-changed="${(e) => this.data = e.detail.value}">
</firebase-document>
`;
}
}
customElements.define('my-view', MyView);
Actually, all of the declarative elements of firebase will not need Polymer nor lit-html / lit-element because they don't need a shadow DOM. That would at least remove a large part and can be used regardless if it is used in Polymer or in another setting or even when used in vanilla HTML.
That I think should be the goal of this repo.
Seems like rxfire is a great match with litElement https://github.com/firebase/firebase-js-sdk/pull/933
The other thing you might consider is breaking out the components into smaller projects (like PolymerElements). It would make it easier to decouple visual from non-visual components and allow their development to proceed apace.
So seriously. I really don't know the future of this element. Hasn't been updated in months. Lacking the latest features from firebase SDK. No sense of direction. Bunch of pull requests which have not been merged for months
It is fine if everyone is busy but at least can anyone direct me in a way I can avoid using polymerfire and go straight with native firebase. My project is 100% polymer V2.
rxFire is releasing soon by the firebase team, I would personally go with that
Sorry, rxFire is basically an extension of the Firebase JS SDK that uses Rxjs, I would recommend using that, it should be fully released soon, here's some documentation https://github.com/firebase/firebase-js-sdk/tree/master/packages/rxfire
Heres an example of using rxFire with Web Components https://youtu.be/fq6UPn5H2Bs
It would also be great if we could see better support for web applications in the Firebase console. Virtually every one of the Analytics components works only with ios/Android. And although this issue is about the Polymer Fire components, I would add that we need components that make it possible to take advantage of the features currently available to ios/Android apps. To that end, I'd like to add to my previous list of components the following:
- An updated messaging component with step-by-step instructions for integrating it into my app. (It would be nice if the starter app included messaging). The current documentation refers to gcm_sender_id which other documentation leads me to believe is deprecated.
- A notification console app that lets me send notifications to my application for testing purposes.
- A remote config element
Given that PolymerFire is not supported for use with Polymer 3 it would make sense to have some use examples for using RXFire with Polymer 3. Most important are Firebase Initialization. User Authentication, including sign in and sign out, and reading and writing data to/from Firestore and Realtime Database. Perhaps using something like the Polymer 3 Starter Kit.
I'm struggling to find anything. Plenty of info and examples for Angular but nothing for Polymer 3. It's extremely frustrating given Firebase, Angular, and Polymer are all in the Google camp. Google sort it out and support and resource Polymer 3 properly please.
My guess is that in Polymer 3 you would use the Polymer JS library instead of the PolymerFire elements. I suspect that they may have some announcements later in the month during the Firebase Summit.
There's an unofficial Polymer3 port of polymerfire here: https://github.com/iceflow19/polymerfire3. Has anyone tried it out? No support for firestore yet.
It would seem the clock is ticking on polymerfire as it is now (polymer 2). HTML imports is deprecated on Google Chrome and will be removed around April 2019 https://www.chromestatus.com/features/5144752345317376. https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/h-JwMiPUnuU/sl79aLoLBQAJ I have a few apps using polymerfire that I would like to update to Polymer 3 but it sounds like there's no easy migration path right now. Perhaps a useful start is a wrapper to use Firebase-JS SDK to help migration of current polymerfire apps to Polymer 3. Then start adding more value with some of suggestions above from: @tjmonsi @phidias51
@phidias51 Looks like https://github.com/iceflow19/polymerfire3 maybe from polymer modulizer: firebase-app.js contains:
FIXME(polymer-modulizer): the above comments were extracted from HTML and may be out of place here. Review them and then delete this comment!
@gdevacc12, @tjmonsi and I were discussing this on Slack. The @iceflow polymerfire3 conversion would be a useful starting point, but @tjmonsi apparently has a polymerfire3 implementation that also includes support for firestore. ATM the @tjmonsi iceflow project doesn't.
The Firebase team seems a bit mum ATM on their plans for polymerfire, and their support for web applications on Firebase always seems to be the red-headed step-child of their development plans.
I can speculate that the support for Polymer3 has been lagging because they've been waiting for Polymer3 to have an official release, but that would seem short-sighted. I know that Firebase has been doing some hiring of late, so maybe they'll start to staff up in this area. It would be good to get some direction from the Firebase team before we go off and waste a bunch of our own time.
Lacking any direction from the Firebase team, my thought has been to create a firefly project group (similar to the PolymerElements project group) that would include a Polymer3 wrapper of the JS library, and would include some of the GUI components that I listed earlier. I have implementations for Polymer2 that I would convert over and donate to the project. I know that there are others that have GUI auth components that they might be willing to donate. At least if it's under a single umbrella github group, it would be easier for users to find.
That said, I have a few caveats:
-
I have "usage patterns" for these components and I don't know how "standard" they are. For example, I use "detail panel" components which provide the detail for a single record, and have a dialog wrapper that wraps the detail panel and lets you add a record to a card list. To edit the record there's a detail page which wraps the detail panel and provides record querying & update capabilities.
-
I also use custom claims to do role-based authorisation, so the user doesn't see parts of the UI that aren't relevant to their role. This is currently implemented as a mixin, and the components could be separated into secure and non-secure versions.
-
Currently the components make use of paper components, but as I understand it MDC web components are waiting in the wings (not sure of the projected release date). In any case, I suspect a fair amount of rewriting would be required.
I'm wondering if we simply check-in what we have (regardless of its current condition), and then work on it until it's in a releaseable condition. Neither @tjmonsi or I have a lot of free time on our hands right now, so it would require the community to step up. A demo project would also be useful to make testing easier and would make it easier for people to see and express the usage patterns that they have in mind.
@phidias51, I completely agree with you, it would be very useful to have some roadmap from Firebase/Google. There's no sense in wasting effort of they are going to produce something. Your proposal sounds like positive step and in any case. Even if some of the components you propose are not "standard" for everyone. No doubt they would fit some use cases and help developers with examples to adapt for other cases. There also seems to be a move in Polymer to MDC. The MDC roadmap https://github.com/material-components/material-components-web/blob/master/ROADMAP.md shows
Polish and bug fixes for release 0.43 December 2018 timeframe.
Probably working with MDC is more work but more to be gained.
The Firebase team is not actively working on updates for PolymerFire, nor is (to my knowledge) anyone from the Polymer team. I am fully supportive of efforts of the community to maintain, support, or replace the library as it is unlikely to see further additional "official" investment. I know this might be disappointing to hear, but I'd rather be honest and set you folks free to do as you'd like 🤘
Web support more broadly is still very much alive for Firebase, and if anything will only see increased investment in the future.
I hope that clears things upa bit, thank you all for your comments and contributions!
On Sat, Nov 24, 2018, 10:44 AM Steve <[email protected] wrote:
@phidias51 https://github.com/phidias51, I completely agree with you, it would be very useful to have some roadmap from Firebase/Google. There's no sense in wasting effort of they are going to produce something. Your proposal sounds like positive step and in any case. Even if some of the components you propose are not "standard" for everyone. No doubt they would fit some use cases and help developers with examples to adapt for other cases. There also seems to be a move in Polymer to MDC. The MDC roadmap https://github.com/material-components/material-components-web/blob/master/ROADMAP.md http://url shows
Polish and bug fixes for release 0.43 December 2018 timeframe.
Probably working on MDC is more work but more to be gained.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/FirebaseExtended/polymerfire/issues/353#issuecomment-441387637, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAD_sfWE7YmTqoIdW2LNW6AVTNkbx1zks5uyZN-gaJpZM4UfXS- .
