Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support ViewComponent 3.0, by using with_SLOT api instead of deprecated 2.x slot API #240

Closed
wants to merge 1 commit into from

Conversation

jrochkind
Copy link
Member

Blacklight 7.34.0 now allows view_component 3.x (as well as 2.x). (the release-7.x Blacklight branch had for some time too).

In trying to upgrade by Blacklight 7 app to BL 7.34.0 and view_component 3.x, I realized that blacklight_range_limit was not yet view_component 3.x compatible.

To make it so, we have to switch to using the new with_SLOT_NAME slot API, from the 2.x deprecated slot API.

Deprecated 2.x Slot API was taken away in view_component 3.0.0. By switching to with_SLOT_NAME API, we can support view_component 3.x.

The with_SLOTNAME API was introduced in view_component 2.54.0 (May 2022). So we now express a dependency requiring view_component at least 2.54.0. As we do use view_components directly in source code here, it is appropriate to express it as a dependency, instead of just leaving it an indirect dependency.

So blacklight_range_limit still supports view_component 2.x (as long as >= 2.54.0) as well as 3.x.

I have tested this (with both view_component 2.82.0 and view_component 3.6.0) in my actually existing app as well.

Deprecated 2.x Slot API was taken away in view_component [3.0.0](https://viewcomponent.org/CHANGELOG.html#v300).  By switching to with_SLOT_NAME API, we can support view_component 3.x.

The with_SLOTNAME API was introduced in view_component [2.54.0](https://viewcomponent.org/CHANGELOG.html#2540) (May 2022).  So we now express a dependency requiring view_component at least 2.54.0. As we do use view_components directly in source code here, it is appropriate to express it as a dependency, instead of just leaving it an indirect dependency.
@jrochkind
Copy link
Member Author

jrochkind commented Oct 4, 2023

Oops, I see @barmintor already took a stab at this at #239, which is equivalent to this, except he makes an additional (unrelated?) fix, and does not change the gemspec.

That seems to be failing for unrelated reasons. This is failing for same unrelated reasons.

@jrochkind
Copy link
Member Author

dup, handled in #242 instead

@jrochkind jrochkind closed this Oct 11, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant