[PP-2] Remove InputBehaviorsBlockSettingsForm and consolidate with input components form

📌 Implement saving block settings forms Active is done, that now only leaves 🐛 Some components cannot be used in XB because UI prevents SDC props being named `name` Active .

I don't think this is strictly dependent on the meta. It is important to get done and it's also related to landing the code components, because they will need a third type of props form (albeit likely very similar to the SDC one), not sure if we should unify them all before or after that lands.

Bumping priority because 🌱 [Meta] Plan for code components Active is very actively being worked on for 🌱 Milestone 0.2.0: Experience Builder-rendered nodes Active .

I support this issue, but why is this a prerequisite for code components? The code components' input UX form should be IDENTICAL IN EVERY WAY as for SDCs. Is this issue really a hard blocker for that?

#5: it isn't. Which is why ✨ Create a ComponentSource plugin for JS components Active landed without this having happened :)

📌 Maintain a per-component set of prop expressions/sources Active just landed, and it introduced the concept of SimpleComponent + ComponentModel (used on the client to make components from BlockComponent work) and PropSourceComponent + EvaluatedComponentModel (used by the client to make components from SingleDirectoryComponent and JsComponent work).

Yes I think this can land and I think some of the changes in 📌 Will passing the model props for a component via GET parameters hit limitations due to URL length Active highlight that we need to make sure the #parents are consistent - in fact they should be applied in the ComponenteInputForm rather than in each source plugin. That will move this closer I think - will try to take a stab at this before the end of the week

(The bits that 📌 [PP-1] Implement client-side validation of block settings Active will be able to remove are now very easy: remove one private helper method, remove one line.)

wim leers → credited balintbrews → .

@balintbrews responded to @longwave's review feedback 😊

Well well … npm run build works fine (meaning tsc doesn't complain), but the result actually does not execute 😬

(I've reproduced it locally: same exact Uncaught ReferenceError: Cannot access 's1' before initialization error.)

This is all just due to the tiny clean-up/tightening I did based on @longwave and @balintbrews' feedback at https://git.drupalcode.org/project/experience_builder/-/merge_requests/6....

I'm baffled that TypeScript appears to succeed, but compiles to something invalid 😱

Automatically closed - issue fixed for 2 weeks with no activity.