Closed hasghari closed 3 years ago
Not sure why the Travis build is not showing up in the GitHub checks but all the tests are passing: https://www.travis-ci.com/github/hasghari/routing-filter
Just realized that even though it's backwards compatible with earlier Rails versions, this PR does break compatibility with any custom filters implemented.
@hasghari do you plan to update this to solve the custom filters issue?
@hasghari do you plan to update this to solve the custom filters issue?
I think that depends on what the maintainer of this project wants to do. If they are comfortable with releasing a new version which breaks backwards-compatibility, then I can clean up this PR to remove the code that retains compatibility with earlier versions.
However if the desire is to do a minor release and not break backwards compatibility, then I can look into doing that.
Unfortunately I have not heard back from any of the maintainers.
Feel free to prepare only 6.1 oriented release. There are no new features added to this library anymore. The only purpose is maintenance.
Feel free to prepare only 6.1 oriented release. There are no new features added to this library anymore. The only purpose is maintenance.
@simi I've updated the PR for Rails 6.1 only. You can find the build here: https://www.travis-ci.com/github/hasghari/routing-filter
An update to Changelog with hints for what to look out for when upgrading would be nice. For example clarifying that the result received from yield
when running around_generate
etc will now be a wrapper class object rather than a basic 2 element Array.
:wave:, upgrade guide would be nice. Anyway I'm wondering why anyone is still using routing filter in 2021. Can anyone please share their usecase?
@simi we are still using it. We inherited that decision so it's just part of the core application's fabric at this point. It's used to send folks between v1 and v2 versions of our endpoints.
We're using routing-filter in a 17 year old Rails app (https://mynewsdesk.com).
Mainly for supporting customers hosting pages on our app on their own domain via CNAME. We have a lot of gnarly routing logic going on to support customers external domains (eg. subdomain.<customer-domain>.com
), customer related subdomains on our own domain (eg. <customer-name>.mynewsdesk.com
) as well as static internal subdomains on our own domain (eg. www.mynewsdesk.com
, amp.mynewsdesk.com
etc).
Main takeaway: Never ever use subdomains for routing if you can do it with regular path's instead 😬
Thanks for the info. I was just wondering why you can't easily migrate to built-in Rails functionality today.
Anyway I'll take a look, merge and release new version soon.
I've used it to solve exactly the first use case "Conditionally prepending the locale" - routing-filter was great to help solve that. Maybe there is a way to do that in Rails now but I tried a few experiments at the time and couldnt find a way to make it work.
We're using it (and this branch right now) for the same case as pmackay, to allow conditional prepending of the locale.
👋, upgrade guide would be nice. Anyway I'm wondering why anyone is still using routing filter in 2021. Can anyone please share their usecase?
It still seems to be in Refinery CMS. I tried upgrading to 6.1.1 from 6.0.3 and bumped into it again. I'll have a look at where it is used.
Oh, in refinerycms-i18n
, so locales .
We are also using (or at least suggesting to use) this gem in solidus_i18n.
👋, upgrade guide would be nice. Anyway I'm wondering why anyone is still using routing filter in 2021. Can anyone please share their usecase?
Using this for routing affiliates in an insurance multi-rater.
Will a new version with this merge be released any time soon?
@svenfuchs Do you mind if we review and merge this? We're up against it with recent changes to Mimemagic's licensing and subsequent removal of all historic gems requiring a rails upgrade. I've had a look at the code in this PR and it looks fine to me but I'm definitely lacking the context that you have.
Thanks @simi
This PR maintains backwards compatibility with previous versions of Rails. All tests have been updated to use
path_for
instead ofgenerate
since the latter is only an intermediate result, not the final value for a generated rails path.