Refactor: decouples storage and framework identifiers, supports forking frameworks - #16
Open
alail-ims wants to merge 1 commit into
Open
Refactor: decouples storage and framework identifiers, supports forking frameworks#16alail-ims wants to merge 1 commit into
alail-ims wants to merge 1 commit into
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
In order to support forking a mirrored framework and regenerating/minting new identifiers, this changeset decouples the storage and framework identifiers.
Previously, frameworks were persisted inside of a file whose name included the identifier of said framework (which is how they were looked up). This could be problematic when it comes to re-minting identifiers on a forking change since we're changing not just the identifiers but also how the framework is stored under the hood, all while said framework is still open in the browser. Moving forward with this approach would mean having to do a delicate dance of updating data behind the scenes and making sure the frontend state is still valid.
Moving forward, when a framework is imported a "storageId" gets generated, which follows a given framework for the entirety of its lifetime, regardless of how it might change.
All forward facing APIs still have the same contracts, and continue to use the public identifiers as they did before. Behind the scenes when a call is made that requires reaching into the filestore, the framework's identifier is used as a lookup to get the actual storageId.