🔷 [Epic] Support component versioning by blockheight

[mpeterdev]

Description

Parity feature

When embedding another BOS component, it should be possible to provide a blockheight at which a version of that component was published in order to lock to that version

Providing a blockheight which does not correspond to a publish should throw an error

Syntax does not need to match VM implementation

Resources

1. VM implementation

[mpeterdev]

we may wish for default behavior to differ from the VM implementation, see https://github.com/NearSocial/VM/discussions/102

[mpeterdev]

@andy-haynes if we move to default version locking, we could do some interesting performance optimizations where the metadata of a component includes an array of all down-tree components such that when loading a root component we may only need to do one subsequent bulk source fetch to get the remainder of the components which will be rendered. This would likely require static analysis at time of writing the component, and it may not be perfect, but even a best effort could lead to significantly less request waterfall during load

[andy-haynes]

That could be a massive improvement for loading across the board.

It would be pretty straightforward to use the same tree parsing logic in both places (for setting the metadata and parsing Components without metadata).

[mpeterdev]

@gabehamilton Am I correct that it would be most effective to power a fetch like this via Query API since we would be aggregating data across a number of SocialDB keys and blockheights?

[gabehamilton]

Yes, QueryApi would be great for that. A couple of indexers have been written to look at widgets. We'd need to put some time into designing the data structures in particular but here are some examples.

• Simple Example
• Complex Example
• with Dependencies

[mpeterdev]

we'll move forward with this with a pure SocialDB get implementation and consider QueryAPI usage when we get to performance optimizations

[gabehamilton]

Sounds good. The components indexer is populated. They can be fetched here

like

query ComponentByBlockheight {
  dataplatform_near_components_versions(
    where: {component_author_id: {_eq: "near"}, component_name: {_eq: "AccountAutocomplete"}, block_height: {_eq: 107226941}}
  ) {
    code
    component_name
    component_author_id
    block_height
  }
}

[mpeterdev]

likely implemented by supporting import MyComponent from near://michaelpeter.near/MyComponent@<blockheight>

[mpeterdev]

https://t.me/c/1881788227/46

this should ideally be addressed in a way that all tooling does not need to separately implement it