Skip to content
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

TASK: Make single-field Value Objects stringable #5241

Merged
merged 1 commit into from
Sep 11, 2024

Conversation

bwaidelich
Copy link
Member

@bwaidelich bwaidelich commented Sep 6, 2024

Implement the magic __toString() method in relevant core value objects that represent a single string value.

Note: This also adds and configures a PHPStan rule that disallows implicit casting in for those

Related: #5239
Reverts parts of #4156

Implement the magic `__toString()` method to relevant core value objects that represent a single string value.

Note: This also adds and configures a PHPStan rule that disallows implicit casting in for those

Related: #5239
Base automatically changed from feature/5239-stringable-value-objects to 9.0 September 6, 2024 15:54
@bwaidelich bwaidelich marked this pull request as ready for review September 6, 2024 16:08
@kitsunet kitsunet closed this Sep 6, 2024
@kitsunet kitsunet reopened this Sep 6, 2024
Copy link
Member

@kitsunet kitsunet left a comment

Choose a reason for hiding this comment

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

Looks good to me :)

Copy link
Member

@mhsdesign mhsdesign left a comment

Choose a reason for hiding this comment

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

Looks good so far, but i dont know if we got em all? According to your list at #4156 we forgot ContentDimensionId

@nezaniel nezaniel assigned nezaniel and unassigned nezaniel Sep 11, 2024
@nezaniel nezaniel self-requested a review September 11, 2024 17:12
Copy link
Member

@nezaniel nezaniel left a comment

Choose a reason for hiding this comment

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

Looks good!

@nezaniel nezaniel merged commit 514e55a into 9.0 Sep 11, 2024
14 checks passed
@nezaniel nezaniel deleted the feature/5239-stringable-value-objects-2 branch September 11, 2024 17:13
@mhsdesign
Copy link
Member

I fell like one question is left unanswered. Now with stringcastable things again in fusion do we still need the newly introduced flowqueries? 🤯

#5046

  • ${q(node).id()}
  • ${q(node).nodeTypeName()}

because node.aggregateId and node.nodeTypeName will also work perfectly and cast to a string.

I just updated all our rector migrations 🤦🤦🤦🤦🤦🤦🤦🤦🤦🤦🤦🤦🤦🤦🤦🤦🤦🤦🤦🤦🤦

@kitsunet
Copy link
Member

I do kinda like them still because suddenly we could change the API without affecting fusion.

@mhsdesign
Copy link
Member

On the otherhand i think its really valuable to have one way of doing it instead of 2 or multiple ones. There should be always one clear solution so that people dont have to come up with too many guidelines for their own projects. I mean neos was always opinionated so why not this time as well?

mhsdesign added a commit to mhsdesign/neos-development-collection that referenced this pull request Oct 8, 2024
…query operations

with neos#5241 value object were made string-able, so they are simply usable in fusion after all.

Previously flowquery operations were introduced to not have to do the manual string cast via `.value` in `node.nodeTypeName.value` and similar.

The label flowquery operation was introduced in the same run but now we reconsidered that flowquery should mostly be used for traversal and the only real final operation is get().

For this reason we also discourage the property operation now. The negative performance aspect of 8.3 of needlesly resolving all reference nodes by calling `node.properties.title` is dated as now only real properties are ever in the result set.
neos-bot pushed a commit to neos/contentrepository-nodeaccess that referenced this pull request Oct 14, 2024
…query operations

with neos/neos-development-collection#5241 value object were made string-able, so they are simply usable in fusion after all.

Previously flowquery operations were introduced to not have to do the manual string cast via `.value` in `node.nodeTypeName.value` and similar.

The label flowquery operation was introduced in the same run but now we reconsidered that flowquery should mostly be used for traversal and the only real final operation is get().

For this reason we also discourage the property operation now. The negative performance aspect of 8.3 of needlesly resolving all reference nodes by calling `node.properties.title` is dated as now only real properties are ever in the result set.
neos-bot pushed a commit to neos/neos that referenced this pull request Oct 14, 2024
…query operations

with neos/neos-development-collection#5241 value object were made string-able, so they are simply usable in fusion after all.

Previously flowquery operations were introduced to not have to do the manual string cast via `.value` in `node.nodeTypeName.value` and similar.

The label flowquery operation was introduced in the same run but now we reconsidered that flowquery should mostly be used for traversal and the only real final operation is get().

For this reason we also discourage the property operation now. The negative performance aspect of 8.3 of needlesly resolving all reference nodes by calling `node.properties.title` is dated as now only real properties are ever in the result set.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants