Replies: 1 comment 5 replies
-
|
I'm curious to see what more knowledgeable people will have to say. But I have to figure that the best approach is to not do what you're describing - just use the same htmx version across teams. As far as I'm aware, there's rarely if ever, any breaking changes - v2 major version is largely just to remove IE support. |
Beta Was this translation helpful? Give feedback.
-
|
When I want to use htmx extensively, it carries a certain risk in our setup. I have to trust the htmx community that they will never make a breaking change. Otherwise i will be very hard to make it happen without a downtime. |
Beta Was this translation helpful? Give feedback.
-
|
Doesn't this happen for literally every package and tool that you use? As for htmx in particular, even if there was a major breaking change, you could just continue without upgrading - it's not like any of the underlying http and browser APIs are going to change/break any time soon... |
Beta Was this translation helpful? Give feedback.
-
Yes, exactly. With Rollup or Webpack and multiple instances of Vue/React(with scoping) that use these dependencies, the issue is resolved.
What if the htmx community decides to make a breaking change that requires modifications before the new version can be used? One team lacks the capacity/resources (for whatever reasons) to make those changes and doesn’t want to upgrade. However, the other team is ready to do so. Please consider the micro-frontends pattern in mind. This will not be possible. |
Beta Was this translation helpful? Give feedback.
-
|
When I said "Doesn't this happen for literally every package and tool that you use?" I meant isn't a breaking change a risk with every package you use? And then you just confirmed how this is a non-issue - you use different versions when needed. Youre worrying too much about a breaking change at literally the worst possible time - they're literally making a new major version that DOESN'T have any breaking changes other than dropping IE support. If some day far in the future real breaking changes are made (I doubt it), then you can do what you're already doing - use the version that is compatible. I don't see how microfrontends is relevant. Anyway, good luck to you |
Beta Was this translation helpful? Give feedback.
-
|
I think the point here is, if you are using microfrontends, then every team releases their own complete stack including frontend markup independently. If htmx is defined as a common dependency that is present globally on the page, upgrading htmx would imply testing all stacks against this new version before you can roll it out. This of course increases the coupling between teams and makes them less independent. Also, if only one team encounters a breaking change, all other teams are forced to stay at an older (possibly insecure?) version. And with i.e. vue this can be solved as it is possible to have multiple versions used on the same page and every team can upgrade in their own pace without blocking others. |
Beta Was this translation helpful? Give feedback.
-
We employ the micro-frontends pattern to consolidate multiple service frontends into a single unified frontend. However, in scenarios where different teams utilize varying versions of htmx, potential compatibility issues may arise. Is there a mechanism to restrict htmx to specific DOM nodes? Consider a situation where one team employs htmx 1.9.11, while another team uses htmx 2.0.0 within the same page.
As a point of comparison, Vue.js allows for the instantiation of multiple versions, as demonstrated in their documentation on multiple application instances.
Beta Was this translation helpful? Give feedback.
All reactions