Rails own 'form_for' / 'form_with' helper

[skorth]

Hey there,

nice to see hashid turning into its own rails gem. But what about form_for and form_with helpers in Rails? If i want to obscure ID's within URL's it works fine. Using form_for would generate its CLASS and ID automatically by using to_key and reveal the original ID within the DOM. What do you think, is that something that should be addressed?

[jcypret]

Hi @skorth. Thanks for bringing this up! I was able to recreate using the view helper dom_id(@model, :action). Hadn't considered that scenario before.

Looks like overriding to_key instead of to_param would sort things out, but need to review typical usage. It makes sense conceptually that the model's key would be the hashid, not the database id.

[mikehatfield]

@jcypret Any updated thoughts on this topic?

[AlphonseSantoro]

We tried to override to_key in our project and quickly found that the gem devise uses this method to find the record using a where statement with the id, and this will not work if to_key returns the hashid.

I think considering to override record_key_for_dom_id in ActionView::RecordIdentifier is better, the documentation also says you can override it if you want.

# Returns a string representation of the key attribute(s) that is suitable for use in an HTML DOM id.
# This can be overwritten to customize the default generated string representation if desired.
# If you need to read back a key from a dom_id in order to query for the underlying database record,
# you should write a helper like 'person_record_from_dom_id' that will extract the key either based
# on the default implementation (which just joins all key attributes with '_') or on your own
# overwritten version of the method. By default, this implementation passes the key string through a
# method that replaces all characters that are invalid inside DOM ids, with valid ones. You need to
# make sure yourself that your dom ids are valid, in case you override this method.