Support for array methods like arrayUnion

[takshch]

Description

Exports methods like arrayUnion

Change from current to suggested

Current

const { FieldValue } = this.store.firebase.firebase.firestore;
const data = {
    searches: FieldValue.arrayUnion(this.searchValue),
};

const ref = this.store.doc(....);
await ref.save(data);

Suggested

import { arrayUnion } from 'zuglet/firestore';

const data = {
    searches: arrayUnion(this.searchValue),
};

const ref = this.store.doc(....);
await ref.save(data);

[takshch]

@ampatspell I think this is needed. I also want to work on this! So, can you please review this and make some changes to make it better.

Idea is to make zuglet/firestore like firestore package as mentioned in the link https://firebase.google.com/docs/firestore/manage-data/add-data

[ampatspell]

currently there is store.serverTimestamp. how about we deprecate that then too and add:

import { serverTimestamp, arrayUnion } from 'zuglet/store';

let a = serverTimestamp();
let b = arrayUnion(arg);

essentially store is firestore in zuglet.

also arrayUnion will need a case in: https://github.com/ampatspell/ember-cli-zuglet/blob/master/addon/-private/model/properties/object.js#L27-L42

[takshch]

"firebase/firestore" also exports methods like doc, setDoc, addDoc, collection.

// models/message.js
import EmberObject from '@ember/object';
import { inject as service } from '@ember/service';
import { activate } from 'zuglet/decorators';
import { doc } from 'zuglet/store';

export default class Message extends EmberObject {
  @tracked id;

  @activate().content(
     ({ store, id }) => doc(`messages/${id}`).existing()
  )  doc;
}

Injecting a store in models every time is like sticking with something tightly. It's like a boilerplate. How about removing the need of store in model?

[ampatspell]

doc, collection creates references. that is covered by store.doc() and store.collection()

regarding store service, app can have multiple stores, each with separate firebase project configuration. when you interact with a store, you're referencing one particular connection.

https://github.com/ampatspell/ember-cli-zuglet/blob/master/blueprints/ember-cli-zuglet/files/__root__/instance-initializers/__name__-store.js#L7-L21

initialize(app, {
  store: {
    identifier: 'firstStore',
    factory: FirstStore
  }
});

initialize(app, {
  store: {
    identifier: 'secondStore',
    factory: SecondStore
  }
});

[takshch]

I don't think people will use 2 or more firebase projects in their ember app.

What do you think?

[takshch]

Can you please tell me what is <%= classifiedPackageName %> in export default class <%= classifiedPackageName %>Store extends Store and how it is supported in js?

https://github.com/ampatspell/ember-cli-zuglet/blob/master/blueprints/ember-cli-zuglet/files/__root__/store.js#L48

[ampatspell]

I don't think people will use 2 or more firebase projects in their ember app.

that's certainly something I want to support for dashboard-style applications

[ampatspell]

classifiedPackageName

that is ember-cli blueprint variable, those files are used to generate store, application route when you do ember install or ember g ember-cli-zuglet: https://cli.emberjs.com/release/advanced-use/blueprints/

[takshch]

that's certainly something I want to support for dashboard-style applications

What are dashboard-style applications? Why do those applications need multiple stores?

[takshch]

@ampatspell Can you please reply?

[ampatspell]

Oh, sorry, missed your comment.

Let's say you have multiple firebase apps (separate projectIds) and you want to build some kind of overview dashboard app that shows information gathered from all the apps.

[takshch]

It makes sense. Then zuglet/store is fine!

import { serverTimestamp, arrayUnion } from 'zuglet/store';

Do you have anything in mind to refine this?

[ampatspell]

Looks good to me

[takshch]

@ampatspell I will understand the codebase and will send the PR for this issue.

[takshch]

@ampatspell I tried to understand the code but it is really hard to understand it without documentation. I got to know a few little things.

Can you please write the architecture of the library with a UML diagram?

[ampatspell]

That would be way too much effort.

Everything revolves around custom registry registrations: https://github.com/ampatspell/ember-cli-zuglet/blob/master/app/initializers/zuglet-internal.js

Basically there are 2 bigger groups of code:

• "global" – stores, stats
• store and everything that has store reference (firestore, storage, auth, functions). Each of them could be viewed in relative isolation. See storage which is way simpler then firestore but works the same way.