The local/remote option for form helpers should have been called navigate or background

A May Of WTFs
1

The remote/local option for form helpers could have been named better.

Last I checked both options send a request from the local client to the remote server, the difference being if it’s full-page navigation (implemented as a native HTML form) or it’s a background request (fetch/xhr/ajax).

Maybe I’m just not understanding the terminology here. Can someone tell me what is local about the following form?

form_with url: "/search", method: :get, local: true

I’d much rather it use “navigate: true” or “background: false”

form_with url: "/search", method: :get, navigate: true

form_with url: "/search", method: :get, background: false
1 Like
2

Don’t know about local, but remote felt pretty intuitive to me even when I was just starting out, ie. when I click this link / submit this form, something happens elsewhere (ie. remotely).

On first impression, the terms navigate / background require me to process additional mental context. Is navigate some browser configuration option which doesn’t have a simpler term like visit? Does background control CSS background color?

Naming is hardddd.

3

Correct, Naming is hard.

Currently the form_for and form_tag have have been soft deprecated in Favor of form_with. Change-proposal, Docs-change-pr

Meaning that the “remote” option is being replaced with “local” in the newer form_with. Other possible options for this could be full_navigation, xhr/ajax/fetch, or background_request.

Either way I’d consider both variations to be “remote” unless this is an SPA that doesn’t submit the form data to a remote server. An example would be the Squoosh app that compresses images locally and therefore doesn’t send the form data to a remote server.