Hello Cat GPT

removing not needed method

[Live] Emit system for component-to-component communication!

feature #765 [Live] Emit system for component-to-component communication! (weaverryan)

This PR was squashed before being merged into the 2.x branch.

Discussion

[Live] Emit system for component-to-component communication!

| Q | A | ------------- | --- | Bug fix? | no | New feature? | yes | Tickets | Fix #163 | License | MIT

Hi!

This PR - which is modeled after Livewire's excellent emitting system - adds a way for a component to communicate to another components by emitting an event. You could use this to, for example, emit an event in ComponentA to trigger ComponentB to re-render itself... which is exactly what's described in #163.

• [ ] Possibly add a way to dispatch a DOM event from PHP

Cheers!

Commits

04171eae [Live] Emit system for component-to-component communication!

[Live] Fix parent->child fingerprint problem + always match child component

feature #766 [Live] Fix parent->child fingerprint problem + always match child component (weaverryan)

This PR was squashed before being merged into the 2.x branch.

Discussion

[Live] Fix parent->child fingerprint problem + always match child component

| Q | A | ------------- | --- | Bug fix? | yes | New feature? | no | Tickets | None | License | MIT

Another boring PR from me to prep for 2.8 :P. This is caused by a few different changes to the system mixing together. Fixes:

A) If a parent component re-renders and the "input props" that are passed to the child differ, the child should re-render with the updated "input props". That broken in 2.8 due to a checksum problem. No fixed, and a new updateFromParent was added to opt into this behavior, which makes most parent-child situations simpler.

B) When a parent component re-renders and the "input props" that are passed to the child have NOT changed, we render a "dummy" child element (so that we don't need to use the CPU to render a component that doesn't need to be updated). This was already the case, but until now, we always rendered as a div (even if the original child were an li). I had thought we could "get away" with this (as we are discarding that fake, empty element anyways), but we couldn't. So now we render the correct tag always.

Cheers!

Commits

ee4536ef [Live] Fix parent->child fingerprint problem + always match child component

[Live] Emit system for component-to-component communication!

feature #765 [Live] Emit system for component-to-component communication! (weaverryan)

This PR was squashed before being merged into the 2.x branch.

Discussion

[Live] Emit system for component-to-component communication!

| Q | A | ------------- | --- | Bug fix? | no | New feature? | yes | Tickets | Fix #163 | License | MIT

Hi!

This PR - which is modeled after Livewire's excellent emitting system - adds a way for a component to communicate to another components by emitting an event. You could use this to, for example, emit an event in ComponentA to trigger ComponentB to re-render itself... which is exactly what's described in #163.

• [ ] Possibly add a way to dispatch a DOM event from PHP

Cheers!

Commits

04171eae [Live] Emit system for component-to-component communication!

[Live] Fix parent->child fingerprint problem + always match child component

feature #766 [Live] Fix parent->child fingerprint problem + always match child component (weaverryan)

This PR was squashed before being merged into the 2.x branch.

Discussion

[Live] Fix parent->child fingerprint problem + always match child component

| Q | A | ------------- | --- | Bug fix? | yes | New feature? | no | Tickets | None | License | MIT

Another boring PR from me to prep for 2.8 :P. This is caused by a few different changes to the system mixing together. Fixes:

A) If a parent component re-renders and the "input props" that are passed to the child differ, the child should re-render with the updated "input props". That broken in 2.8 due to a checksum problem. No fixed, and a new updateFromParent was added to opt into this behavior, which makes most parent-child situations simpler.

B) When a parent component re-renders and the "input props" that are passed to the child have NOT changed, we render a "dummy" child element (so that we don't need to use the CPU to render a component that doesn't need to be updated). This was already the case, but until now, we always rendered as a div (even if the original child were an li). I had thought we could "get away" with this (as we are discarding that fake, empty element anyways), but we couldn't. So now we render the correct tag always.

Cheers!

Commits

ee4536ef [Live] Fix parent->child fingerprint problem + always match child component

Merge remote-tracking branch 'origin/2.x' into live-emit-events

• origin/2.x: [Live] Fix parent->child fingerprint problem + always match child component [Live] Emit system for component-to-component communication!

| Q | A | ------------- | --- | Bug fix? | yes | New feature? | no | Tickets | None | License | MIT

Another boring PR from me to prep for 2.8 :P. This is caused by a few different changes to the system mixing together. Fixes:

A) If a parent component re-renders and the "input props" that are passed to the child differ, the child should re-render with the updated "input props". That broken in 2.8 due to a checksum problem. No fixed, and a new updateFromParent was added to opt into this behavior, which makes most parent-child situations simpler.

B) When a parent component re-renders and the "input props" that are passed to the child have NOT changed, we render a "dummy" child element (so that we don't need to use the CPU to render a component that doesn't need to be updated). This was already the case, but until now, we always rendered as a div (even if the original child were an li). I had thought we could "get away" with this (as we are discarding that fake, empty element anyways), but we couldn't. So now we render the correct tag always.

Cheers!

[Live] Fix parent->child fingerprint problem + always match child component

feature #766 [Live] Fix parent->child fingerprint problem + always match child component (weaverryan)

This PR was squashed before being merged into the 2.x branch.

Discussion

[Live] Fix parent->child fingerprint problem + always match child component

| Q | A | ------------- | --- | Bug fix? | yes | New feature? | no | Tickets | None | License | MIT

Another boring PR from me to prep for 2.8 :P. This is caused by a few different changes to the system mixing together. Fixes:

A) If a parent component re-renders and the "input props" that are passed to the child differ, the child should re-render with the updated "input props". That broken in 2.8 due to a checksum problem. No fixed, and a new updateFromParent was added to opt into this behavior, which makes most parent-child situations simpler.

B) When a parent component re-renders and the "input props" that are passed to the child have NOT changed, we render a "dummy" child element (so that we don't need to use the CPU to render a component that doesn't need to be updated). This was already the case, but until now, we always rendered as a div (even if the original child were an li). I had thought we could "get away" with this (as we are discarding that fake, empty element anyways), but we couldn't. So now we render the correct tag always.

Cheers!

Commits

ee4536ef [Live] Fix parent->child fingerprint problem + always match child component

[Live] Fix parent->child fingerprint problem + always match child component

[Live] Emit system for component-to-component communication!

feature #765 [Live] Emit system for component-to-component communication! (weaverryan)

This PR was squashed before being merged into the 2.x branch.

Discussion

[Live] Emit system for component-to-component communication!

| Q | A | ------------- | --- | Bug fix? | no | New feature? | yes | Tickets | Fix #163 | License | MIT

Hi!

This PR - which is modeled after Livewire's excellent emitting system - adds a way for a component to communicate to another components by emitting an event. You could use this to, for example, emit an event in ComponentA to trigger ComponentB to re-render itself... which is exactly what's described in #163.

• [ ] Possibly add a way to dispatch a DOM event from PHP

Cheers!

Commits

04171eae [Live] Emit system for component-to-component communication!

Fix parent->child fingerprint problem

Also fixes using the correct element for children always

built js

adding versionadded

| Q | A | ------------- | --- | Bug fix? | no | New feature? | yes | Tickets | Fix #163 | License | MIT

Hi!

This PR - which is modeled after Livewire's excellent emitting system - adds a way for a component to communicate to another components by emitting an event. You could use this to, for example, emit an event in ComponentA to trigger ComponentB to re-render itself... which is exactly what's described in #163.

• [ ] Possibly add a way to dispatch a DOM event from PHP

Cheers!

I have a child component which has an "add item" form, and when this submits, it persists a new entity. This works fine.

However, the parent component is showing a list of the persisted entities - how can I reload the parent component to show the updated list when the child component finished submitting? (it's a "Choose product" form, and then "Add to basket" type thing.)

I've read the docs about the parent and child both having a model property with the same name etc, but there is no model to share here. I would have thought this is a common behaviour, but I just cannot find a way to get it working. Any ideas?

Thanks

[Live] Emit system for component-to-component communication!

feature #765 [Live] Emit system for component-to-component communication! (weaverryan)

This PR was squashed before being merged into the 2.x branch.

Discussion

[Live] Emit system for component-to-component communication!

| Q | A | ------------- | --- | Bug fix? | no | New feature? | yes | Tickets | Fix #163 | License | MIT

Hi!

This PR - which is modeled after Livewire's excellent emitting system - adds a way for a component to communicate to another components by emitting an event. You could use this to, for example, emit an event in ComponentA to trigger ComponentB to re-render itself... which is exactly what's described in #163.

• [ ] Possibly add a way to dispatch a DOM event from PHP

Cheers!

Commits

04171eae [Live] Emit system for component-to-component communication!

[Live] Emit system for component-to-component communication!

build and test fix

emit component modifier -> name

Use Required attribute + simpler prop name

optional args

built js

| Q | A | ------------- | --- | Bug fix? | yes | New feature? | no | Tickets | None | License | MIT

Another boring PR from me to prep for 2.8 :P. This is caused by a few different changes to the system mixing together. Fixes:

A) If a parent component re-renders and the "input props" that are passed to the child differ, the child should re-render with the updated "input props". That broken in 2.8 due to a checksum problem. No fixed, and a new updateFromParent was added to opt into this behavior, which makes most parent-child situations simpler.

B) When a parent component re-renders and the "input props" that are passed to the child have NOT changed, we render a "dummy" child element (so that we don't need to use the CPU to render a component that doesn't need to be updated). This was already the case, but until now, we always rendered as a div (even if the original child were an li). I had thought we could "get away" with this (as we are discarding that fake, empty element anyways), but we couldn't. So now we render the correct tag always.

Cheers!

Fix parent->child fingerprint problem

Also fixes using the correct element for children always

Fixing invalid XML

more fixes

| Q | A | ------------- | --- | Branch? | 5.4 | Bug fix? | yes | New feature? | no | Deprecations? | no | Tickets | None | License | MIT | Doc PR | Not needed

It looks like #49848 accidentally introduced a syntax not compat with php 7.2/7.3. So, an annoying little PR to fix that.

Fixing more tests

fixing tests