[107] Update button variants to match new variants in bitstyles update

[ArinzeJeffrey-droid]

107

[andreasknoepfle]

Updating form 4 to 6 is quite something. Wouldn't it be better to go small steps? We want bitstyles_phoenix to be backwards compatible to older projects as well (when updating the bitstyles_phoenix version without updating bitstyles).

We spend quite some efforts to upkeep this and need to continue this for our running projects at least.

We should talk about this again before continuing here...

[planktonic]

@andreasknoepfle yes, probably something we should discuss 👍

The main change is that bitstyles buttons now have two axis of variants — they can be different sizes, and different colors. One from each can be combined, but not multiple (small + primary or large + outline etc is good, but small + large or primary + outline makes no sense).

Is the main change here that breaks backwards compatibility the switch to using two attributes? (one for color-variant, one for size-variant) We could keep using the single attribute to handle both, if that avoids the problem

[andreasknoepfle]

Is the main change here that breaks backwards compatibility the switch to using two attributes? (one for color-variant, one for size-variant) We could keep using the single attribute to handle both, if that avoids the problem

With jumping 2 major versions I can't say what are changes that break compatibility. But what I can say is that in this PR the tools that we have set up for maintaining compatibility have been ignored so far.

Tbh I would probably start from scratch and just take this as an inspiration in order to migrate to 6.0

[planktonic]

With jumping 2 major versions I can't say what are changes that break compatibility

To be clear, these changes to buttons (using two combinable attributes, form and Color) were almost the only thing to change in v5 (from the PoV of the components. Many other technical changes happened on which future improvements can happen). So this PR could be set to v5 if that makes it easier somehow?

I’ll take a look through and see if I can find out how we can use the backwards-compatibility functionality here, but any pointers you have would also be very welcome 🙏

[andreasknoepfle]

I am not quite sure how the new buttons work (haven't checked yet), but what you want to do in general is map the classes of v5 to classnames of v4 in here: https://github.com/bitcrowd/bitstyles_phoenix/blob/main/lib/bitstyles_phoenix/bitstyles.ex and then use the v5 classes in the codebase on the various components. Keep in mind that the mapping of classes only works when the classes in the components run through the classnames/* helpers.

For now it was always possible to do this mapping like that, but if there is a more high level change needed in some component, you could access Application.get_env(:bitstyles_phoenix, :bitstyles_version) in a helper and create 2 versions of that component. One with the old and one with the new classes. The old classes might then want to call the mapping function in https://github.com/bitcrowd/bitstyles_phoenix/blob/main/lib/bitstyles_phoenix/bitstyles.ex directly, or pass the version to use along somehow if using classnames will lead to errors (but that is unlikely).

[planktonic]

Thanks @andreasknoepfle, we’ll try the classnames first and see if it’s enough

[angelikatyborska]

Superseded by https://github.com/bitcrowd/bitstyles_phoenix/pull/125