-
-
Notifications
You must be signed in to change notification settings - Fork 394
[LiveComponents] Hello Component JS Object #500
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
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
This was referenced Oct 11, 2022
fc3bd76 to
5cc495a
Compare
# This is the 1st commit message: WIP heavy refactoring to Component Initial "hook" system used to reset model field after re-render Adding a 2nd hook to handle window unloaded reinit polling after re-render Adding Component proxy # This is the commit message #2: fixing some tests # This is the commit message #3: Refactoring loading to a hook # This is the commit message #4: fixing tests # This is the commit message #5: rearranging # This is the commit message #6: Refactoring polling to a separate class
* hook system used to reset model field after re-render * Adding Component proxy
and removing originalData - new child logic will not need this
This will be needed later for child component handling, where the server will send down a list of updated "props" only, and the client side will need to update the props of a component, without changing the "data" that may have already been altered by the user.
…stem Also removing redundant event (there is a hook)
making the plugin system a bit more formal
Fixing bad test exposed by new inability to compare promise resolve callback Removing old child test
…a model updating CHANGELOG
Also refactored to a new DehydratedComponent
…and parents Adding DeterministicIdCalculator and giving child components data-live-id
more minor refactoring inside LiveComponentSubscriber
initial attempt at conditional child rendering upgrading browser
…arents And fixing bug where deterministic id calculator was not deterministic after all Previously, the template name used in the id was the top-level template name, not the "final" one that actually rendered the component.
… components This also includes the dispatching of several new PHP events. Documenting hooks + minor items
096a67f to
aac55bf
Compare
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.
Hi!
This is effectively a rewrite of the LiveComponents frontend (with minimal effect on users). It introduces:
A) A
Componentobject that "mirrors" your PHP component object and lives in a__componentproperty of your element - this allows you to do cool things like:B) Logic is much more organized between
live_controller.ts(mostly event listening & initialization),Component.ts(model+action & Ajax handling) and a number of "plugins" that add loading, polling, etc).C) Child handling is more intelligent: child components will NOT re-render when their parent component re-renders, unless the data passed into the child has changed. It does this by generating a "fingerprint" (checksum) of the values that are passed into a child component when
{{ component() }}is called. Then, when a parent re-renders, the "fingerprints" if its children are sent with the request. If any of those fingerprints are seen to have changed during the re-render, then we know the "input" to a child has changed and the child should be re-rendered (which is done basically by sending a signal to the child component to re-render itself with a new set of props).D) Child/parent data passing is now done with a
dataModelprop.TODOs:
v-model(previously calleddata-model-map) ability: where a child can communicate a model change to its parentdata(writable props) &propsseparately as live controller valuesdata-live-idattribute to the child unless manually specifiedchildrenFingerprintsdata for GET (JSON-encoded query param) and POST (request body). Use this to compare to the NEW fingerprint value for each child. If not changed, render the child as an empty element (with onlydata-live-id). If changed, render an empty element, but withdata-live-id, the new fingerprintdata-value and the newdata-live-props-value.Cheers!