@versile2 what do you think?

@versile2 what do you think?

I think this part of the code base is not my expertise and I do not have adequate time to review/learn it. I believe @ScarletKuro is probably the most knowledgeable here.

I think this part of the code base is not my expertise and I do not have adequate time to review/learn it. I believe @ScarletKuro is probably the most knowledgeable here.

I don’t like the use of IsChildOriginatedChange here. We don’t use it and even try to avoid it, it was mainly introduced to cover external use cases and back then I thought it was really good idea to distinguish the source, but now I think If you need to distinguish whether a change was propagated from a parent update or originated within the component itself, it feels like a band-aid solution.
In my opinion, we should strive for validation to run consistently whenever a value changes, regardless of the source. The origin of the change shouldn’t matter.
I would even consider removing IsChildOriginatedChange in future, since we don’t use it ourselves. The parameter-state is niche, it's barely used outside of our team and Mud, since unfortunately it’s tied to Mud. I wish it were a standalone NuGet package usable across different UI frameworks, the code itself is actually independent. And in that case, it might make more sense to have it.
I’ve also noticed that AI tends to really love to use it to get things done quickly, but that often leads away from a proper architectural solution.

Feel free to prove me wrong whatever it's really necessary here.

IsChildOriginatedChange

I totally agree with removing the IsChildOriginatedChange for validation, I actually didn't notice the reason of using it as AI used it, sorry for that, next time I will take a better look.
About removing the IsChildOriginatedChange in the future, I don't have too much deep knowledge about the project, but I went throught some files and really think that could be a good idea, if I could help with it and learn a little bit more

Thank you!