make an "add as friend" web component

[SharonStrats]

This moves over the code from profile-pane for adding as a friend and creates a Web Component from the code.

[Copilot]

Pull request overview

Introduces a new solid-ui-button-add-friend web component by extracting the “add as friend” behavior into a reusable component, along with supporting helpers, styling, and a Storybook story.

Changes:

• Added ButtonAddFriend web component that checks login state, detects existing friendships, and performs the FOAF knows mutation.
• Added helper to ensure standard RDF prefixes are registered for rdflib mutations.
• Added component styling and a Storybook story for basic states.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 7 comments.

Show a summary per file

File	Description
src/components/button-add-friend/index.ts	Barrel export for the new add-friend component.
src/components/button-add-friend/helpers.ts	Adds prefix-registration helper used before rdflib updates.
src/components/button-add-friend/ButtonAddFriend.ts	Implements the add-friend web component and mutation logic.
src/components/button-add-friend/ButtonAddFriend.styles.css	Styles the inline status banner shown on error.
src/components/button-add-friend/ButtonAddFriend.stories.ts	Storybook coverage for guest/logged-in/friend-exists states.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[timea-solid]

Looks ok to me, but I would appreciate Noels review.

[NoelDeMartin]

I think the general direction is ok, but there are a couple of things that should be improved to make this more "idiomatic".

Also, regarding the name, maybe it should be called "add-friend-button" instead? I worry this is too specific to be in the generic solid-ui package, but I understand we're doing this to use it in two different panes so I guess it's ok. Whenever we prepare developer documentation, we should probably make sure that this type of component is in a different section or something (also using storybook groups, etc.).

[NoelDeMartin]

We shouldn't be passing the context as an attribute, it should be a context provided by a parent component. We already do this with the auth context, so we could reuse that one or create a dedicated one for the store.

Timea has been working on this, and she's leaning more towards having a separate "StoreContext". Check it out in her PR, as they should both follow the same approach: #798

[SharonStrats]

I should probably wait until Timea merges that PR then so i can use the store she added.

[timea-solid]

I am not entirely sure what Noel was explaining.
What is the context here? What does this web component need to know?
Regarding the store - in all code we can get the store directly from solid-logic. In RDF forms we have a way to pass in a store for the sole purpose of using the RDF forms standalone, without solid-logic. So why would we need this option for this component? (This I never understood).

[NoelDeMartin]

I am not entirely sure what Noel was explaining.

With context I meant the context attribute for the component. Instead of an attribute, it should be a value provided with @lit/context. And yes, we should still be able to pass anything in case we want to override it (such as a store in the RDF Forms), but context (as in Lit context) should be the best practice.

That's just a suggestion, though, and how I think this should work... It's not impossible to pass the context directly as an attribute if that's the design choice we want to make. But I think it would be inconsistent to how we've been building all the other components.

[SharonStrats]

@NoelDeMartin I added it as context, but then when I was trying to use it I ran into the decision on how the context should be provided. Are you able to share your vision about the providers we should have?

We have the solid-ui-provider for instance that only has 'auth', should this also provide the store? Or should the component/pane that is using it have a provider for the store?

If the idea is that we should have the store on the solid-ui-provider, what is our intention with the DataBrowserContext from solid-logic/pane-registry? Should this become smaller or obsolete as we convert the panes to web components?

I've written something up about the structure and redesign here https://sharon.pivot-test.solidproject.org:3000/public/MashlibDesign.md. I would love to hear your thoughts.

Note: when i created that document some research suggested that the solid logic store was stale, but when i dived deeper I don't think this is true. I think we can use the store in solid logic for the resource service to get content for the source pane. (I'll update this later) If you have an opinion about this I'd love to hear it.

[NoelDeMartin]

We have the solid-ui-provider for instance that only has 'auth', should this also provide the store? Or should the component/pane that is using it have a provider for the store?

Yes, I think it'd make sense to provide it in solid-ui-provider as well, that way consumers of solid-ui only need one wrapper to their application and it provides all the necessary contexts. Though this is the part that I was saying can depend on how we solve this for RDF forms. As far as I understand, RDF Form also need access to a global store, and ideally it should use the same that we use here.

If the idea is that we should have the store on the solid-ui-provider, what is our intention with the DataBrowserContext from solid-logic/pane-registry? Should this become smaller or obsolete as we convert the panes to web components?

I'm not familiar with DataBrowserContext, but as far as I understand it, yes it should probably become obsolete in favour of Web Components. Everything we have in that context can probably be moved to an object provided by @lit/context.