Publishing code components

This number shows the total number of instances that will be affected by the basic card component update.

So is this if you are making a new component or editing an existing it shows how many times the JS component is place

So for example:

1. New or existing Component, but no instances in Unpublished Changes or already published = 0
2. Existing Component
   Unpublished changes: 2 instances added in Page A, 1 instance added in Page B
   Already Published: 3 instances in Page C,
   = 6
3. Existing Component:
   Unpublished changes, 1 instance added in Page A, 1 instance removed in Page C
   Already published 3 instances in Page C,

= 3? because there will be instances once "Publish all" is submitted?

Clicking view swaps the modal to a deeper view of which
pages are affected

What about if

1. You have 2 existing code components, A & B
2. the code component B is used inside code component A
3. Code Component B has been edited but Code component A has not

Would the "deeper view " show that Code Component A has been affected? Would it should all pages where code component A is used but not B directly? Because these pages would have changes resulting from B changes
Would the number 46 in the example image take into account all Component B placements?

I am wondering if it would make sense to start an MR hear that would add a ComponentUsageCalculator service. Because we are going to need some way to find how many usage particular component has. I guess this will be across content entities using a Json field query, but also we would need to loop take into account instances inside `PageTemplate` .

For PageTemplate entities is it just important show a list of which regions would be affected? Would this only for the active theme? I can imagine in some sites they make start with 1 theme, places some code components in regions but then decide to switch to another theme and not bother to uninstall the other theme. But in other sites they may have custom code or a module like https://www.drupal.org/project/theme_switcher → switches themes.

I think to find the number of pages or content entities in general that use a specific component we might need 📌 Ensure querying JSON nested values when parent keys are unknown is possible in all supported databases Needs work or more likely 📌 Calculate field and component dependencies on save and store them in an easy to retrieve format Active

I will research this further

Up until now, the XB team has been following a pseudo-scrum/pseudo-kanban process, but we're now shifting into more conventional scrum. We started a new 2-week sprint last Thursday (Jan 16). I'm tagging our current sprint's issues for visibility. This one I'm tagging with "spike" rather than "sprint", because our goal isn't to complete the implementation of it this sprint, but to refine its details.

Related: https://git.drupalcode.org/project/experience_builder/-/merge_requests/5... — in ✨ HTTP API for code component config entities Active .

working on this

We might want to update `ApiPendingChangesControllerTest` to handle an Code Component in auto-save.

✨ Auto-save code components Active is in. 🎉

@wim leers thanks for finishing this up!

You left it in a great spot, was a pleasure! :)

For #3: 🌱 Plan to allow editing props and slots for exposed code components Active .

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