Skip to content
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

Support for array methods like arrayUnion #295

Open
takshch opened this issue Apr 14, 2022 · 16 comments
Open

Support for array methods like arrayUnion #295

takshch opened this issue Apr 14, 2022 · 16 comments

Comments

@takshch
Copy link

takshch commented Apr 14, 2022

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
Copy link
Author

takshch commented Apr 14, 2022

@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
Copy link
Owner

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
Copy link
Author

takshch commented Apr 20, 2022

"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
Copy link
Owner

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
Copy link
Author

takshch commented Apr 23, 2022

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

What do you think?

@takshch
Copy link
Author

takshch commented Apr 23, 2022

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
Copy link
Owner

ampatspell commented Apr 24, 2022

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
Copy link
Owner

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
Copy link
Author

takshch commented Apr 24, 2022

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
Copy link
Author

takshch commented Apr 29, 2022

@ampatspell Can you please reply?

@ampatspell
Copy link
Owner

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
Copy link
Author

takshch commented Apr 30, 2022

It makes sense.
Then zuglet/store is fine!

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

Do you have anything in mind to refine this?

@ampatspell
Copy link
Owner

Looks good to me

@takshch
Copy link
Author

takshch commented May 4, 2022

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

@takshch
Copy link
Author

takshch commented May 7, 2022

@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
Copy link
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants