Store and calculate dependencies in `JavaScriptComponent`

So it's the client side that will specify a list of JavaScriptComponent config entity IDs in js_dependencies, and it's then up to the server side to accurately respect this in ::calculateDependencies(), resulting in those config dependencies getting listed under dependencies.config.

Is that right?

If so, this is the config schema change you're proposing:

diff --git a/config/schema/experience_builder.schema.yml b/config/schema/experience_builder.schema.yml
index 3a79adf2b..dae25a06b 100644
--- a/config/schema/experience_builder.schema.yml
+++ b/config/schema/experience_builder.schema.yml
@@ -142,6 +142,15 @@ experience_builder.js_component.*:
     css:
       type: experience_builder.compilable_code
       label: 'CSS'
+    js_dependencies:
+      type: sequence
+      orderby: value
+      sequence:
+        type: string
+        constraints:
+          NotBlank: []
+          ConfigExists:
+            prefix: experience_builder.js_component.
 
 experience_builder.page_region.*:
   type: config_entity

Concern: I think js_dependencies is an ambiguous name, because it could be interpreted as a dependency on external JS.

But it really is about capturing dependencies on other JS components.

So I'd prefer it to be named imported_js_components.

FYI

Introduce a imported_js_components property on the JavaScriptComponent config entity to store an array of JS component machine names.

… is literally why I opposed/was very concerned about 📌 JavaScriptComponent config entities should have mutable machineNames Active … and this is where it starts to indeed be a problem, unless I'm mistaken? 🤓😇

I intentionally left #3503272 out of the scope. As of right now, machine name is the primary key of JavaScriptComponent entities. Once that changes, we'll need to revisit changes in this issue.

#7: 👍

Are you okay with the implementation plan changes I made in #3?

Also: what does mean? 🤔

balintbrews → credited tedbow → .

#10: I'm fine with that change, sure.

#11: I was still working on creating other issues under 🌱 [Plan] First-party code component imports Active , and I wanted to add a reference to make that clear. I updated the issue summary now. That part will need more work, I won't be able to define what's exactly needed there, but I had a call with @tedbow to discuss the high-level requirements, and he was fine with what is being proposed.

👍

This blocks ✨ [PP-1] Build import maps for code component dependencies, attach their CSS Postponed .

Assigning to @tedbow to clarify the auto-save bits in this issue.

IMHO it'd be better to split this issue up:

• purely config entity changes in this MR
• auto-save concerns in a follow-up

… but I defer to @tedbow on deciding: whatever's handiest/most pragmatic works 😄

@wim leers would it possible to use the enforced dependencies system for this directly instead of adding js_dependencies to the entity schema?

I have added an MR that does this but I am not sure if this is how the dependencies property of config entities is supposed to be used.

If the general idea would work I can clean it up and add more testing. If it won't I can add the schema changes.

Don't need a full review just an idea if this idea is workable or not

wim leers → credited effulgentsia → .

Well on track, with some direction based on the discussion we just had with @effulgentsia :)

By updating enforced config dependencies directly we don't actually need to update the config schema

I think it is ready for review

Shaping up nicely, but I think it needs a little bit more finetuning 😊

tests failing

The test should be passing now. @wim leers if they are not feel free to assign it back to me

Tests coverage looks excellent now, thank you so much, @tedbow!

There's a few openapi.yml concerns I'd like to see fixed prior to merging.

tedbow → credited hooroomoo → .

Thanks all!

@hooroomoo Pointed out that if we don't send imported_js_components back to the client certain Component client requests will fail.

I would suggest we just send it back since it should not be the client's responsibility to know that `imported_js_components` is stored differently on the back end

#34 Nevermind! The reason I was seeing client requests (PATCH requests for Rename, and Add to component) from the code component contextual menu fail was because the request always included compiled/source_js which caused the error of "missing imported_js_components property"

But because 🐛 PATCH request for config entities reset values that are not sent Active now unblocks 🐛 Adding component to component library results in component code and configuration being lost Active , the frontend can now change the PATCH requests to only include necessary changes, therefore it won't send the compiled/source_js on Rename, Add to component so the error shouldn't happen anymore.

tedbow → closed merge request !905

#35: perfect! That's exactly what I was aiming for 😊🥳