Direction of Polymerfire

[tjmonsi]

@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.

[merlinnot]

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.

[phidias51]

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.

[tjmonsi]

@merlinnot I laughed at the polymerfire if not using polymer

[tjmonsi]

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

[merlinnot]

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>
    `;
  }
}

[tjmonsi]

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.

[merlinnot]

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.

[tjmonsi]

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.

[merlinnot]

Hm, so you want to keep it compatible with Polymer 2, or even 1?

[tjmonsi]

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 }));

[FluorescentHallucinogen]

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);

[tjmonsi]

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.

[FluorescentHallucinogen]

@tjmonsi Vanilla web components?