Skip to content

[LiveComponent] add LiveProp name to modifier function #2652

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

Closed
wants to merge 58 commits into from

Conversation

jannes-io
Copy link
Contributor

@jannes-io jannes-io commented Mar 23, 2025

Q A
Bug fix? no
New feature? yes
Docs? yes
Issues Fix #2650
License MIT

Implements proposal 2 from the examples in the RFC.

Personally I would just pass the entire liveprop metadata object to this function instead of only the name, but it's marked internal so I'm not sure if we should be exposing it to users like that.

@carsonbot carsonbot added Feature New Feature LiveComponent Status: Needs Review Needs to be reviewed labels Mar 23, 2025
@jannes-io jannes-io force-pushed the modifier-prop-name branch 2 times, most recently from 631af7c to 0a949c8 Compare March 23, 2025 19:40
@@ -2617,7 +2617,9 @@ definition::

Then the ``query`` value will appear in the URL like ``https://my.domain/search?q=my+query+string``.

If you need to change the parameter name on a specific page, you can leverage the :ref:`modifier <modifier>` option::
If you need to change the parameter name on a specific page, you can leverage the :ref:`modifier <modifier>` option
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A couple of remarks here (unrelated to wether we will move forward with this PR or not :) )

First of all: thank you for thinking immediately "documentation". That's a very nice habit to have.

Now for the changes here: I think we should not change the existing documentation, but instead we may add a dedicated paragraph after this part.

The current version does it jobs, covers the feature and how most developers use it, while keeping things small / easy to understand.

Moreover, using a prefix instead of an alias here would offer less possibilities than before, so we should probably not describe this solution in first examples, but only when a prefix could be justified (many identical components in the same page ? still not sure to be honest)

So here I think a dedicated paragraph after this one, for more advanced use case, could be more appropriate.

@@ -135,7 +135,7 @@ public function withModifier(object $component): self
throw new \LogicException(\sprintf('Method "%s::%s()" given in LiveProp "modifier" does not exist.', $component::class, $modifier));
}

$modifiedLiveProp = $component->{$modifier}($this->liveProp);
$modifiedLiveProp = $component->{$modifier}($this->liveProp, $this->getName());
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For a change like this, a test would be needed. Especially for things related to query, URL, etc.

(The fact tests do pass after your changes does not proves it does work (nor that our current suite of test is good enough, to be fair))

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added to the existing test, I don't see the need to make a separate test for just this param unless there are some edge cases that aren't entirely obvious to me at this time.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's test a page with two instances of same component, different prefix used in the modifier ... and check that the correct one as the good value and not the other :)

@weaverryan
Copy link
Member

weaverryan commented Apr 1, 2025

I personally don't have a big issue with removing the internal. Very thoughtful to realize that issue :).

Alternatively, if there is something you need on the metadata, we could add it to LiveProp

@smnandre
Copy link
Member

smnandre commented Apr 2, 2025

I don't see a problem to pass the second argument 👍
(we should precise in docs this information may not be the original name of the prop in the class)

Passing the metadata is not something I'd love to do, without an absolute need to do so.
Anything we expose cannot then be changed afterwards.. And it did bring us in situations were we're a bit "stuck" to move forward / improve features.

@jannes-io
Copy link
Contributor Author

jannes-io commented Apr 6, 2025

I don't see a problem to pass the second argument 👍 (we should precise in docs this information may not be the original name of the prop in the class)

Okidoki, I can do the requested changes to the docs and add some tests to finish off this PR. Could you give me a case where the property name could be different from the name in the metadata? Or where I could find code that could create this side-effect so I can try to reproduce? Just want to understand what the implications might be there.

Passing the metadata is not something I'd love to do, without an absolute need to do so. Anything we expose cannot then be changed afterwards.. And it did bring us in situations were we're a bit "stuck" to move forward / improve features.

Agreed 😄

@jannes-io jannes-io force-pushed the modifier-prop-name branch from 0a949c8 to d3c8127 Compare April 6, 2025 13:56
Comment on lines +2654 to +2656
.. versionadded:: 2.25

The property name is passed into the modifier function since LiveComponents 2.25.
Copy link
Contributor Author

@jannes-io jannes-io Apr 6, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This'd have to be updated to the actual release version, I just took the next one.

@jannes-io jannes-io requested a review from smnandre April 6, 2025 13:57
@jannes-io
Copy link
Contributor Author

@smnandre , @weaverryan Is there anything I can do to move this along?

Comment on lines +2661 to +2686
abstract class AbstractSearchModule
{
#[LiveProp(writable: true, url: true, modifier: 'modifyQueryProp')]
public string $query = '';

protected string $urlPrefix = '';

public function modifyQueryProp(LiveProp $liveProp, string $propName): LiveProp
{
if ($this->urlPrefix) {
return $liveProp->withUrl(new UrlMapping(as: $this->urlPrefix.'-'.$propName));
}
return $liveProp;
}
}

#[AsLiveComponent]
class ImportantSearchModule extends AbstractSearchModule
{
}

#[AsLiveComponent]
class SecondarySearchModule extends AbstractSearchModule
{
protected string $urlPrefix = 'secondary';
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm wondering.. could we find use an example more focused on the feature than the PHP code structure abstract/extends here ?

I was thinking something like "imagine you have a CMS theme editor with a split view allowing you to adjust your design both in light and dark mode. ...

You could use a ColorTheme LiveComponent for both, but then [describe problem]

<twig:ColorSettings prefix="dark" color="..." />

<twig:ColorSettings prefix="light" color="..." />

Thanks to the second parameter of YYY, you can dynamically prefix [...].

    #[LiveProp]
     public string $theme;

     #[LiveProp(url: true, modifier: 'prefixParam')]
     public string $color;

       public function prefixParam($liveProp, string $propName): LiveProp
       {
               return $liveProp->withUrl(
                  // Light Theme will use ?light-color
                   new UrlMapping(as: $this->prefix.'-'.$propName)
              );
       }

Now your query parameters will be: XXX ZZZ

It even works with the as: property ..

     // query param will be ZZZ

      #[LiveProp(url: true, as: 'bg' modifier: 'prefixParam')]
      public string $background;      

wdyt ?

@smnandre
Copy link
Member

LGTM, and we will improve the docs afterwards

(changelog must be updated, though)

@jannes-io jannes-io force-pushed the modifier-prop-name branch from d3c8127 to 09b1d86 Compare May 16, 2025 16:18
@jannes-io
Copy link
Contributor Author

(changelog must be updated, though)

Done.

As for the other remarks, apologies for not getting back to you on that.

  1. For the test, I didn't find an existing test where actual LiveComponents are rendered on a page. I'm afraid I'm a little out of my depth to be the first to produce such a test. If there is such a test that can be easily copied and modified to test the new parameter, and I just missed it, I can take a look.
  2. For the docs, it feels to me like the feature is adequately technically documented, we don't look at docs to read a story, we're there for information on how to use features so we can use them in our own stories. If someone wants to rewrite it with a better example, that's fair 😆

Thanks for your assistance.

seb-jean and others added 11 commits May 16, 2025 18:31
The following features were moved in the changelog as they are not present in the 2.23 release, but will be included in the 2.24 release

-  `id` to `Marker`, `Polygon` and `Polyline` constructors
-  `Map::removeMarker(string|Marker $markerOrId)`
-  `Map::removePolygon(string|Polygon $polygonOrId)`
-  `Map::removePolyline(string|Polyline $polylineOrId)`
i missed that i need the http-client installed, the bundle silently reduces functionality without it. make it more clear what needs to be installed
…-notifier

Co-authored-by: Simon André <smn.andre@gmail.com>
The check failed here because file changed .. but with no content change.
Kocal and others added 22 commits May 16, 2025 18:32
…ed in Symfony 7.1 and we want to support at least Symfony 6.4
…t to use, remove ux_toolkit.kit parameter, remove DependencyInjection configuration
…umentation tabs rendering into ToolkitService
… to render the highlighted code inside a Terminal component
…es (from their documentation), with a snapshot system
…ra on PHP < 8.2, since it now supports PHP 8.1
@jannes-io jannes-io force-pushed the modifier-prop-name branch from f761127 to ad75701 Compare May 16, 2025 16:33
@jannes-io jannes-io requested a review from Kocal as a code owner May 16, 2025 16:33
@jannes-io jannes-io changed the base branch from 2.x to 1.x May 16, 2025 16:33
@jannes-io jannes-io changed the base branch from 1.x to 2.x May 16, 2025 16:33
@jannes-io
Copy link
Contributor Author

What in tarnation happened here... Fabbot told me not to merge, so I rebased, and now all this crap is in here..

CBA to fiddle with git, remade it here: #2744

@jannes-io jannes-io closed this May 16, 2025
Kocal added a commit that referenced this pull request May 23, 2025
…econd parameter of the `modifier` callback (jannes-io)

This PR was merged into the 2.x branch.

Discussion
----------

[LiveComponent] `LiveProp`: Pass the property name as second parameter of the `modifier` callback

supersedes #2652

Commits
-------

8fb5245 [LiveComponent] Add property name to modifier function
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature New Feature LiveComponent Status: Needs Review Needs to be reviewed
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[LiveComponent] Include prop name in the url modifier function