Adding component to component library results in component code and configuration being lost

I took a look, and what happens here is that if we use the contextual menu from the sidebar list, we will send the canonical entity data with the PATCH request when we update the JavaScriptComponent entity to rename it or make it internal/exposed, because that's what we have available in the React component that outputs that list. With a new code component which hasn't been published since it was created, it means that only the auto-saved version has the data — and we lose all of that. 🙈

This isn't a cache invalidation problem, because the endpoint that lists the code components doesn't use auto-saved data. To solve the issue, we need to:

1. Fix 🐛 PATCH request for config entities reset values that are not sent Active (priority increased)
2. Update our PATCH requests to include only the wanted changes:
   • ui/src/features/code-editor/dialogs/AddToComponentsDialog.tsx
   • ui/src/features/code-editor/dialogs/RemoveFromComponentsDialog.tsx
   • ui/src/features/code-editor/dialogs/RenameCodeComponentDialog.tsx

🐛 PATCH request for config entities reset values that are not sent Active is in!

Seeing some strange behavior after adding a code component to the library, the JS doesn't load...

This issue surfaced 📌 Add a route for PATCHing both a config entity and its auto-saved version together Active which I think the rest of the stuff that's here is blocked on until that's resolved.

🐛 PATCH request for config entities reset values that are not sent Active landed 20 days ago. 😅

Ah, but 📌 Add a route for PATCHing both a config entity and its auto-saved version together Active is net new!

@hooroomoo I've got a working MR up at 📌 Add a route for PATCHing both a config entity and its auto-saved version together Active , can you give that a try? 🙏

#12. Thanks, I applied your MR 937 from 📌 Add a route for PATCHing both a config entity and its auto-saved version together Active and it fixes the issue reported in the issue summary and it shows the current auto-saved JS and CSS when I open the code editor for the component.

But when I add the component to the layout page preview, the CSS isn't there. The CSS file for the component inside of /sites/default/astro-island never gets created.

#13: What are the steps to reproduce that? Is that reproducible:

• on HEAD
• with only this MR
• with only #3519634's MR
• only by having both this MR + #3519634's MR applied

?

IOW: is it safe to merge #3519634, or does that somehow introduce the problem you're describing? If so, we're lacking some tests, because 📌 Add a route for PATCHing both a config entity and its auto-saved version together Active is passing tests. 😅

Steps to reproduce:

1. Checkout this MR https://git.drupalcode.org/project/experience_builder/-/merge_requests/906. This MR contains frontend changes to only include desired changes in the PATCH requests AND #3519634's MR from yesterday.

2. Create a new code component
3. Make any change to the JS or CSS.
4. Click "Add to components" using the top right button in the code editor (NOT from the contextual menu)
5. After Adding it to components, the compiled JS and CSS file doesn't get generated in /sites/default/files/astro-island. When you click Add to components, the expected behavior is those files gets generated in that directory.

In step 3, that's the code component's CSS and JS, not the global CSS, right? Because 🐛 Global AssetLibrary should render with its auto-saved state (if any) when rendered in the XB UI Active is a known bug.

Correct, step 3 - Make any change to the code component's JS or CSS.

📌 Add a route for PATCHing both a config entity and its auto-saved version together Active is in — with @hooroomoo's approval 🥳

📌 Add a route for PATCHing both a config entity and its auto-saved version together Active fixes this issue :) Closing as outdated

hooroomoo → changed the visibility of the branch 3513147-using-actions-from to hidden.

hooroomoo → closed merge request !906