Refactor FEmptyWishlist/FExportWishlist

[candela97]

1. Refactor the export wishlist dialog to use the new builder.
2. Merge FEmptyWishlist and FExportWishlist into a single feature so we can easily manage feature order and button styles. I used button instead of div elements to avoid a11y issues, but I think it looks alright.

[tfedor]

I'm not really sure what I think of merging those two into one feature. Was feature order and button styles ever an issue?
For button we should use common components/styles, feature order should not matter because those features are independent.

The entire feature system we have was, I believe, meant to help with keeping independent features independent and if we continue this way we could very easily end up having everything in just context class.

The new FWishlistActionButtons feature is also much less descriptive and could do a lot of things, instead of just FEmptyWishlist and FExport Wishlist.

[candela97]

Feature order matters because these features anchor on to the same node, and changing the order will mess up the spacing, that's why there's a dependency. But ok I'll leave it for now since creating a component for 2 buttons doesn't seem worth it.

[tfedor]

Feature order matters because these features anchor on to the same node, and changing the order will mess up the spacing, that's why there's a dependency. But ok I'll leave it for now since creating a component for 2 buttons doesn't seem worth it.

This is already solved with dependency system, or, if we didn't want to do that, it could be fixed with selector change in these features.

[candela97]

I meant to get rid of the dependency since it only affects visuals and is better done with svelte. There was a similar situation with 3rd-party info on app pages before, and we used to have logic in the content class that inserted anchors to the page before features started loading, how does that sound?

[tfedor]

I meant to get rid of the dependency since it only affects visuals and is better done with svelte.

Right now these features are only dependent because of order of buttons, right? So we can control that with changing selector when applying feature, instead of using dependency system.

There was a similar situation with 3rd-party info on app pages before, and we used to have logic in the content class that inserted anchors to the page before features started loading, how does that sound?

I don't think it's necessary to add anchors for this to work to be honest.