set `created` and `modified` fields on ALL collections as `onPreSave`

[eliataylor]

FireCMS supports a onPreSave method on entity definitions. We need something like

officialSchema.onPreSave = ({ values }) => {

  if (!values.created) values.created = new Date().getTime() / 1000;
  values.modified = new Date().getTime() / 1000;

  return values;
};

to ensure we can orderBy(created | modified)

[Branyer]

@eliataylor acabo de subir un commit a mi rama, la idea era plantearte que en lugar de usar FireCMS para modificar los valores de "create" y "modified" se usaran los triggers de las function de firestore. Lamentablemente firebase no permite escuchar a todos los eventos asi que tendriamos que agregar una function que escuchara las actualizaciones para cada documento. que opinas?

[eliataylor]

estaba pensando lo mismo @Branyer. Gracias!

yo copié un ejemplo aquí: https://github.com/DemocraseeClub/website/blob/master/functions/src/index.ts#L212

que piensas? puedes implementarlo?

[Branyer]

Si claro @eliataylor ya empiezo con eso, ya ayer lo implemente en branyer-dev para las actualizaciones de usuarios.

[Branyer]

Ya esta listo @eliataylor, puedes ver los cambios en la rama branyer-dev

[eliataylor]

ahh. entonces, perfecto @Branyer .

Ha probado que set no se crea en un bucle infinito en onUpdate?

[Branyer]

@eliataylor yeah, valido que no se genere el bucle en esta linea, todo funciona bien

[eliataylor]

excelente.

merge to master y adelantamos :)

[eliataylor]

(una pregunta, tu piensas esta mejor usar onUpdate y onCreate en lugar de onWrite con una condición para created?)

[Branyer]

a mi me gusta usar mas onUpdate y onCreate, ya que es un poco mas descriptivo y especifico. Pero si quieres se puede implementar el onWrite, al fin y al cabo, los dos llevan al mismo resultado.

[eliataylor]

dejalo asi.

podemos cambiarlo si el archivo crezca demasiado.