Introduce and bind components to global app state #368
Conversation
This file contains 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
aduth
added
the
Framework
Assigned in parent component map
|
This looks great, we were looking at doing something similar to help with UI management of the different block editors, such as recording the currently active editor if any. |
This was referenced Apr 5, 2017
|
😍 |
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.
This pull request seeks to introduce a global state powered by Redux. See previous discussion at #360 (comment) . Specifically this will assist in allowing disparate components of the application retrieve and manipulate state of the broader application. Encouraging self-sufficient components will also facilitate future refactoring if components need to be moved or reused.
It also effectively supersedes #361, implementing block UID in the proposed state shape.
Testing Instructions:
Existing behavior should remain unaffected.
Follow-up Tasks:
SET_HTMLmay need to be optimized, especially in current implementation where this is called on everychangeevent of the rendered text-modetextarea.UPDATE_BLOCK, whether to allow the block implementation access to updating top-level properties likeblockTypeor expecting them only to update attributes (and regardless, allowing easy patch updates of attributes).