[Slot&Fill] - Add a new slot to core

Development
1

Hi all,

Slot&Fill has merged! which is an opinionated way to extend foreman core functionality by extending react components, replace deface and more. however, in order to use it, we need to decide about a policy for adding new slots to the core (a slot is an extension point).

Because it is a complex feature, adding new slots should be done gradually in order to test its stability over time, therefore we have a suggestion that a PR with a slot needs an ack from at least one member from the UI team.

documentation is located in our storybook under Slot&Fill section, and stay tuned for upcoming deep dive :slight_smile:

1 Like
2

Thanks @amirfefer :+1:

Some more rules I could think about adding Slots:

  1. Create a Slot PR that only contains the new Slot and add a description in the PR why this Slot is needed. From there we can continue the discussion about this particular slot.

  2. 2 developers must ACK new Slot, 1 must be from the UI team

  3. We should grow gradually as you said, let’s set a rule, once we reached 5 Slots, only allow to double the number of slots every month.

1 Like
3

Expanding this: when a slot is implemented to replace deface, link to the existing implementation(s).

2 Likes
4

That makes sense.

I think core maintainers can handle this fine. I can agree on, that core maintainers are encouraged to consult a member of the UI team.

Where is this coming from? I think that’s overly strict.

I’d like to bring up another point: How are we going to handle Pagelets? I consider them a stable API that core offers, so we should find a backward-compatible method with pagelets.

5

The main reason is that “Slot&Fill” is still an experimental feature and we want to make sure it is stable before we have tons of them.
Once we will decide this experiment is stable and reliable, we can use less strict rules.

6

It was my understanding that pagelets should be the first of the three different ways to extend foreman’s UI to be deprecated as its usage isn’t as widespread.

7

I believe you have the wrong impression here, pagelets are used widespread.

From the top of my head:

  • foreman_omaha
  • katello
  • foreman_register
  • foreman_wreckingball
  • foreman_snapshot_management
  • foreman_welding
  • foreman_monitoring

and one of our internal plugins.
Removing pagelets from core would mean, all the plugins would need to move to react. We’re not there yet, in my opinion. That’s why I’d like to have the possibility for a soft migration.

8

Were you thinking of Deface?

9

Perhaps I was confusing the two but I thought @Marek_Hulan said that pagelets weren’t used that much.

10

Very possible.

Yeah, I didn’t realize they were that widespread. We definitely should provide a soft migration path.

11

Pagelets are used, but comparing to deface, they are not used that much.

I think short term, the goal should be moving out of deface to pagelets or slot/fill. In fact, I’d love to see slot defined for wherever we call render_pagelets_for and long-term settle on one solution. When we discussed this last time on virtual coffee, the reasonable way forward seems to get more slot/fill examples implemented, replacing few defaces (though it was not the primary use case for this feature) and see if that would work as the recommended way to extend our UI (both JS and ERB). Based on how that turns out, we should update our “how to write a plugin” and update plugin template with examples and recommendations.

I believe @amirfefer planned to provide more examples in various plugins. I also tried to stress out, we need someone, who will push this effort further. Pagelets are great and I’m happy there is some use of this, but we never made it standard and we didn’t focus on removing deface. I’d like to avoid having deface (~100 overrides), pagelets (~10 extension points) and slots (another ~10 points) in one year from now.

4 Likes