fix to_param to maximize content #23636
Conversation
|
Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @arthurnn (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
| @@ -100,7 +100,7 @@ def to_param(method_name = nil) | |||
| define_method :to_param do | |||
| if (default = super()) && | |||
| (result = send(method_name).to_s).present? && | |||
| (param = result.squish.truncate(20, separator: /\s/, omission: nil).parameterize).present? | |||
| (param = result.squish.parameterize.truncate(20, separator: /-/, omission: '')).present? | |||
There was a problem hiding this comment.
I think it would be safer to keep parameterize towards the end to not cause any side effects from truncate affect parameterization.
There was a problem hiding this comment.
Please refer to my response near the test for this change (lines 39-44) below.
|
The conflicts are with the |
rab
force-pushed
the
fix-to_param-truncation
branch
from
099b3e0 to
1e720c0
Compare
|
Updated/rebased the fix to be against master now that 5.0.0 is released. The to_param code is unchanged. |
|
👍 please squash to a single commit |
The documentation states that parameter values longer than 20 characters will be truncated by words, but the example shows that a parameter based on "David Heinemeier Hansson" (with id: 125) becomes "125-david" when "David Heinemeier".length == 16 so why so short? The answer lies in the use of the #truncate option omission: nil which seems to have been intended to mean "nothing", but which actually causes the default string "..." to be used. This causes #truncate to cleave words until the "..." can be added and still remain within the requested size of 20 characters. The better option is omission: '' (which is probably what was originally intended). Furthermore, since the use of #parameterize will remove non-alphanumeric characters, we can maximize the useful content of the output by calling parameterize first and then giving truncate a separator: /-/ rather than a space.
rab
force-pushed
the
fix-to_param-truncation
branch
from
3a56345 to
3b49d79
Compare
|
Squashed! |
|
Thanks! This will presumably cause some (URL-based) cache misses, for things that have learned to fit more detail, but that seems fine. /cc @jeremy, Defender of the Cache |
|
Presumably not any more than when the truncation began though. Well, scratch that. It's been there since 4.1 and I only noticed when upgrading an app from 2.3.18 to 4.2.6 so the comment about cache misses is valid. |
To fix #23635
The documentation states that parameter values longer than 20 characters
will be truncated by words, but the example shows that a parameter based
on "David Heinemeier Hansson" (with id: 125) becomes "125-david" when
"David Heinemeier".length == 16 so why so short?
The answer lies in the use of the #truncate option omission: nil which
seems to have been intended to mean "nothing", but which actually causes
the default string "..." to be used. This causes #truncate to cleave
words until the "..." can be added and still remain within the requested
size of 20 characters.
The better option is omission: '' (which is probably what was originally
intended).
Furthermore, since the use of #parameterize will remove non-alphanumeric
characters, we can maximize the useful content of the output by calling
parameterize first and then giving truncate a separator: /-/ rather than
a space.