Meta Programming (@Collection & #Tag Search)

[danalexilewis]

Ever since I used the Toggl timer bar and Slack search I have wished for the @Account #Topic search functions to become a dev standard.

Note: I wrote about this idea in https://github.com/benwinding/react-admin-firebase/issues/59#issuecomment-569374139 if you want to read my initial mumblings.

eg searching in:

Toggl timer bar with Projects and Tags but with out the @ and # drop down feature in the general text area. (incidentilly github does this for people and issues 😅)

Slack search (the first @ and # will create a drop down, but you can't do both with dropdowns.

So this is a feature I would love to have supported out the box for a search implementation...

And to make this work we need to start getting into Meta-programming. ie it would be easy to create a dropdown of @Collections in the search - as long as all collections were known/indexed.

Unless I have missed some key api for getting this info from Firestore I believe we would need to have a collection of collection-types containing the metadata of each of the collections in the system, perhaps including a list of sub-collections? essentially its doing stuff similar to counting the size of the collection over time.

It would be a similar strategy for tags - you would just assume that all documents in a collection can have an optional array field of tags. Then you would create a collection of tags that were available in the system.

If you had these two things in place you would be able to use the firestore query to do a search for a specific collection that contained a specific set of tags.

You could go further and say that all documents have to have a title and then you could do a in react-admin string filter on the title containing any of the key words you typed in to the search after having specified what collections and tags you wanted to search for.

Under the hood you would need to run one query/defined collection.

Noticing: If the @ and # feel to much like power user modes you could just use drop downs like toggl. And then have a text box area that said Filter instead of Search. In other words the query is created by the combination of collections + tags and the fuzzy search text is actually a fuzzy filter text.

---

Back to Meta Programming

So the search feature above is nice, but what I am really excited about is document types for a collection that change the way they are rendered in react-admin/custom app.

ie lets say I have a collection of records and each record declares its record type.

I can then develop a very different rendering rule per record type or per version of a record type, this would allow the data shape of a given object to change overtime without having to introduce default data into previous records.

You could use such a versioning system to drive an A/B ui testing system as well - perfect for developing MVPs.

The last idea I had for this was to build a dev portal for local development and then have the dev use react-admin to create document types that are saved to the development repo as json-schema/typescript interfaces. In theory as we have List guesser and Show guesser we should be able to render out a crud view immediately and if we want generate fake data based on the types.

This would lead to quite a nifty development experience as I could basically boot up my repo model some types into the system, deploy to firebase hosting, trigger the fake data function and tell the client to go to the url and login and interact with there model.

If you got this right - this could be fast enough to pair on them with developing their data objects in realtime

#IDreamADream

[benwinding]

@agentlewis I've been meaning to respond to this idea for a while. I think it has great potential and recent developments in the Firestore api make this much easier to implement than it would have been 6 months ago.

Firebase SDK Changes Which Help I stumbled accross this recent blog post by Firebase, which demonstrates a few new query operators (besides the original: '<' | '<=' | '==' | '>=' | '>' | 'array-contains'), they are:

• in document field string matches one of many values
• array-contains-any document field array matches one of many values

These operators add amazing flexibility to queries and should allow search using some kind of tag implementation. Basically it means we can do AND and OR queries on array fields in documents.

collection('reports')
  .where('status', 'in', ['Open', 'Pending', 'Confirmed'])

collection('reports')
  .where('status', '==', ['Open'])
  .where('tags', 'array-contains-any', ['june', 'difficult', 'large-contract'])

There are some limitations though

Implementation Of Tag Search This could be implemented by passing a list of tags to an <AutocompleteArrayInput> filter component. Which then could be used as a filter query to the list view.

Other notes

I can then develop a very different rendering rule per record type or per version of a record type, this would allow the data shape of a given object to change overtime without having to introduce default data into previous records.

It sounds like you'd like list the behaviour of react-admin's List guesser and Show guesser, but from types instead of json data. This is probably better suited as it's own react-admin module, rather than including it in this one.

essentially its doing stuff similar to counting the size of the collection over time.

It's funny you mention that, I added an answer for that exact question on SO a few months ago

Anyway, appreciate the ideas and hope you're well.

Cheers, Ben

[danalexilewis]

Hey @benwinding thanks for following up, I ended up writing up my thoughts in a readme

Interesting regarding Firebase SDK changes and the collection counting. Good to note.

I am currently working on a project using amplify and one of the things I want to look at is what it takes to use amplify as a backend instead of Firebase. Reason is it doesn't have the same cost/read problem and is graphql out of the box which aligns with my thinking about producing schemas.

However what I can say about my current experience with amplify compared to Firebase is that it is showing its immaturity. Certainly I think at the moment Firebase is more compelling from a dev POV.

But on to your specifics - I think the ideal of passing tags to <AutocompleteArrayInput> makes sense. It would be cool for react-admin-firebase to provide an out the box implementation of a Tag Collection connected to the menu. Then any tags added are then connected to the search function as options.

Then any collection being created can just have a tag field added to it and boom it will work wit the search.

Or something basic like that.

I'm happy to spike on this - curious if you think its worth having as an out the box feature?