support setting at scoped routes#259
Conversation
mikker
left a comment
There was a problem hiding this comment.
Thank you for contributing. Question
| if block_given? | ||
| scope(defaults: pwless_resource.defaults, &block) | ||
| instance_exec(&scope_block) | ||
| else | ||
| instance_exec(&scope_block) |
There was a problem hiding this comment.
I don't see how this solves the problem described?
This talks about running passwordless_for with a block, not inside a scope block?
If block is passed, it runs the block first, then runs passwordless_for exactly like it does now?
Maybe I'm reading it wrong?
|
@mikker You're absolutely right! I've pushed a fix in the latest commit. The route definitions now properly execute within the provided scope context instead of alongside it. When a block is given, the passwordless routes are now correctly nested within that scope.
The key fix was restructuring the logic so that Could you take another look when you have a chance? The scoping should work as intended now. Thanks for the feedback! |
|
@mikker 👋🏽 |
|
Thank you for this. Patience, please. I'll get to it eventually. |


Closes #206
This PR adds support for scoping and nesting of Passwordless routes.
Changes made
Updated
passwordless_formethod inrouter_helpers.rbto:Added comprehensive tests in
router_helpers_test.rbto verify:Updated the README to document the new scoping functionality with examples
The implementation now allows you to use Passwordless routes within any Rails scope, such as:
This will generate routes like:
/:locale/users/sign_in/:locale/users/sign_in/:id/:locale/users/sign_outAnd the corresponding URL helpers:
users_sign_in_path(locale: 'en')users_sign_out_path(locale: 'en')The changes in this PR are fully backward compatible, so existing implementations will continue to work as before.