Transitioning the Indexer from the static tree to the runtime tree

Transitioning the Indexer from the static tree to the runtime tree

Currently, getting the root query of an Om Next app will not return an updated view on the app's query structure if some child instance of the root has changed its query. Transitioning the indexer to the runtime tree would allow a consistent view of the UI tree with respect to query structure. In order to achieve that, a few constraints need to be introduced in the way we allow components to change their queries at runtime.

Possible solutions

Restrict set-query!'s behavior

1. Restricting set-query! such that:

• we only allow an instance to set its query if it satisfies at least one of the following:

  1.1 the instance has a ref, independently of how many instances of such class exist

  • we can get this new query via subquery later

  1.2 there's only one instance of this class in its data-path

  • this is possibly preferred over class-path since it builds directly on the structure of the queries in the app

  1.3. if none of the above apply, we change the query for the class

  • this allows dynamism in setting the query for all the instances of a certain class in a join
  • comparable to setting the query of all posts in a Dashboard similar to the "Queries with Unions" tutorial

2. get-query would need to be modified for component instances in order to make it work with the new semantics of set-query!

• Disadvantages:
  • Because we allow queries to change in a class-wise fashion (see 1.3) and we can't access the reconciler from classes, we can't store these queries in state, or else we won't be able to get them from get-query
  • Because we look for the updated query of a class in get-query, getting the original query is no longer possible and in case we want to support it, a new helper would be necessary (as well as storing the original query as a field in the component class)

3. build-index would most probably be fixed for free because it just uses get-query on the root and goes from there.

4. full-query would also be fixed for free because it leverages the indexes which we fixed in 3).