Add optional metadata field to FeatureFlagState.
#5876
Merged
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
rileyajones
approved these changes
Aug 15, 2022
bmd3k
added a commit
that referenced
this pull request
Aug 17, 2022
Now that we can consume FeatureFlagMetadata from state. (See #5876 and, Googlers, cl/467745607), we can start using it. We update DashboardDeeplinkProvider to use metadata from FeatureFlagState instead of via constructor. The constructor argument is left optional for the time being, until we can update internal code to remove usage. We also make the metadata field mandatory now that it is specified universally.
bmd3k
added a commit
that referenced
this pull request
Aug 22, 2022
…5890) Now that we can use feature flag metadata from state (#5876) we use it in FeatureFlagOverrideDataSource instead of hardcoding the FeatureFlagMetadataMap value. This will actually allow us to delete all internal implementations of TBFeatureFlagDataSource (googlers, see cl/469204869) since all feature flag parsing logic is now controllable via metadata.
yatbear
pushed a commit
to yatbear/tensorboard
that referenced
this pull request
Mar 27, 2023
Add `metadata?: FeatureFlagMetadataMapType` field to FeatureFlagState and populate it in OSS TensorBoard. We have use cases for accessing the Metadata through NgRx state and this is the first step to safely integrating that metadata into state for all TensorBoard instances, internal and external. The optionality of the field will be removed when internal TensorBoards are updated to also populate the metadata field.
yatbear
pushed a commit
to yatbear/tensorboard
that referenced
this pull request
Mar 27, 2023
…5877) Now that we can consume FeatureFlagMetadata from state. (See tensorflow#5876 and, Googlers, cl/467745607), we can start using it. We update DashboardDeeplinkProvider to use metadata from FeatureFlagState instead of via constructor. The constructor argument is left optional for the time being, until we can update internal code to remove usage. We also make the metadata field mandatory now that it is specified universally.
yatbear
pushed a commit
to yatbear/tensorboard
that referenced
this pull request
Mar 27, 2023
…ensorflow#5890) Now that we can use feature flag metadata from state (tensorflow#5876) we use it in FeatureFlagOverrideDataSource instead of hardcoding the FeatureFlagMetadataMap value. This will actually allow us to delete all internal implementations of TBFeatureFlagDataSource (googlers, see cl/469204869) since all feature flag parsing logic is now controllable via metadata.
dna2github
pushed a commit
to dna2fork/tensorboard
that referenced
this pull request
May 1, 2023
Add `metadata?: FeatureFlagMetadataMapType` field to FeatureFlagState and populate it in OSS TensorBoard. We have use cases for accessing the Metadata through NgRx state and this is the first step to safely integrating that metadata into state for all TensorBoard instances, internal and external. The optionality of the field will be removed when internal TensorBoards are updated to also populate the metadata field.
dna2github
pushed a commit
to dna2fork/tensorboard
that referenced
this pull request
May 1, 2023
…5877) Now that we can consume FeatureFlagMetadata from state. (See tensorflow#5876 and, Googlers, cl/467745607), we can start using it. We update DashboardDeeplinkProvider to use metadata from FeatureFlagState instead of via constructor. The constructor argument is left optional for the time being, until we can update internal code to remove usage. We also make the metadata field mandatory now that it is specified universally.
dna2github
pushed a commit
to dna2fork/tensorboard
that referenced
this pull request
May 1, 2023
…ensorflow#5890) Now that we can use feature flag metadata from state (tensorflow#5876) we use it in FeatureFlagOverrideDataSource instead of hardcoding the FeatureFlagMetadataMap value. This will actually allow us to delete all internal implementations of TBFeatureFlagDataSource (googlers, see cl/469204869) since all feature flag parsing logic is now controllable via metadata.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Add
metadata?: FeatureFlagMetadataMapTypefield to FeatureFlagState and populate it in OSS TensorBoard.We have use cases for accessing the Metadata through NgRx state and this is the first step to safely integrating that metadata into state for all TensorBoard instances, internal and external.
The optionality of the field will be removed when internal TensorBoards are updated to also populate the metadata field.