Skip to content

Comments

Routing Guide#7

Open
bhumi1102 wants to merge 75 commits intomainfrom
bhumi-guides-routing
Open

Routing Guide#7
bhumi1102 wants to merge 75 commits intomainfrom
bhumi-guides-routing

Conversation

@bhumi1102
Copy link
Owner

@bhumi1102 bhumi1102 commented May 10, 2024

Hi all - this guide is ready for internal review.

Note: seeing intermittent build failure due to "error creating build container" from docker. I'll look into it but it doesn't have anything to do with the guides. So safe to review this

Here are the notes from the TODO:

  • We mention Rack application right away, good place to link to the Rack guide.
  • Would it make sense to link "CRUD operation" to something like the AR Basics CRUD section? We don't always need to tie CRUD to database, it's more about the concept.
  • Under Path and URL helpers, it might make sense to turn that list into a table to make it easier to scan?
  • Singular resources starts with examples of using get, maybe it should be specific to resource and leave get to Non-Resourceful Routes section? That section doesn't start with "simple" examples.
  • "Because you might want to use the same controller for a singular route (/account) and a plural route (/accounts/45), singular resources map to plural controllers." => I've never seen this be the case, I think this can be reworded to explain that singular resources map to plural controllers, without this idea of "use the same controller".
  • Under shallow nesting, there's a long example with three child resources to demonstrante that "all get the same shallow behavior"... maybe that'd be better with just 2 so that the table doesn't get so big/long.
  • Under creating paths and URLs from objects, it explains how to create paths from objects (i.e. polymorphic routing), that may be a good segway to show that it uses the route key / singular route key from ActiveModel::Naming to figure that out. (could be a note/tip of sorts for example, just thought it'd be good to make that connection somewhere) Also ActiveModel::Conversion#to_param would be used to convert the IDs.
  • member and collection are explained under "Adding more RESTful actions", but there's not a good clarification of what the terms represent, i.e. that member refers to routes acting on a single element, much like show/update/destroy, and collection referes to routes acting on multiple (or a collection of) elements like index. Is it worth clarifying further?
  • Consider: Constraints could be a main section rather than live under non-resourceful routes, because generally speaking, they can be applied anywhere, even for resources. The only specific one would be match...via:
    --> Good point. Tried to move the 3 or 4 sub-sections related to constraints, but couldn't decide where they fit, after non-resource routes or before, and how to transition into them...leaving it as is for now.
  • Under Route Globbing and Wildcard Segments there's a waning about passing format: false related to "old 3.0.x behavior" which can either be explained better (what's the meaning of passing format: false), and/or potentially removed (at least the mention to "3.0.x behavior" could be removed)
  • When explaining about using draw to break down very large route files, that subsection could be a caution/warning of sorts to call more attention to the fact that most people shouldn't need it.
  • We could explain how to check routes via console with Rails.application.routes.url_helpers under inspecting routes.
  • Document the somewhat recent --unused option to rails routes. (Reference)

@bhumi1102 bhumi1102 changed the title Routing Guide Routing Guide (WIP) May 10, 2024
@bhumi1102 bhumi1102 requested a review from OughtPuts June 27, 2024 14:23
@bhumi1102
Copy link
Owner Author

Hi @OughtPuts 👋 nice to meet you. I've added you to this PR as a reviewer!

Copy link
Collaborator

@OughtPuts OughtPuts left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought this was really good and really clear, particularly for those picking it up for the first time! Saw a couple of opportunities for extra clarification as I went through which I commented, but I wouldn't say any of them are major blockers, just ideas. Enjoyed reading - thank you!

Copy link
Collaborator

@OughtPuts OughtPuts left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice job @bhumi1102! Just a few tiny typos I spotted on final read through that we may want to clear up.

The request is matched to the `UsersController` class's `show` method with `{ id: '17' }` in the `params` hash.

The `to:` option expects a `controller#action` format when passed a string. Alternatively, You can pass a symbol and use the `action:` option, instead of `to:`. You can also pass a string without a `#`, in which case the `controller:` option is used instead to `to:`. For example:

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Argh sorry, found a typo. Should this be 'in which case the controller: option is used instead OF to:.

then the router will generate the path `/patients/17`. This reduces the brittleness of your view and makes your code easier to understand. Note that the id does not need to be specified in the route helper.
The router will generate the path `/users/17` from `user_path(@user)`. Using the `user_path` helper allows you to avoid having to hard-code a path in your views. This is helpful if you eventually move the route to a different URL, as you won't need to update the corresponding views.

It also generates `user_url`, which has a similar purpose. While `user_path` generates a relative url like `/users/17`, `user_url` generates an absolute url something like `https://example.com/users/17` in the above example.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the 'something like' reads a bit funny here. Consider rewording to "... generates an absolute url. For the above example this would be https://example.com/users/17."


Each of these `_path` helpers also have a corresponding `_url` helper (such as `photos_url`) which returns the same path prefixed with the current host, port, and path prefix.

TIP: The prefix used before "_path" and "_url" is the route name and can be identified by looking at the "prefix" column of the `rails routes` command output. To learn more see [Listing existing routes](#listing-existing-routes) below.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

'Listing Existing Routes' should be capitalized.

TIP: If your application has many RESTful routes, using `:only` and `:except` to
generate only the routes that you actually need can cut down on memory use and
speed up the routing process by eliminating [unused
routed](#listing-unused-routes).
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Link text should be 'unused routes'.

bhumi1102 and others added 5 commits August 22, 2024 13:55
bhumi1102 pushed a commit that referenced this pull request Dec 11, 2025
* Active storage immediate variants (#6)

* This commit introduces variant generation strategies for Active Storage,
providing more flexible control over when variants are created.

- **:lazily** - variants created dynamically when requested (default)
- **:later** - variants created in background after attachment
- **:immediately** - variants created simultaneously with attachment

```ruby
has_one_attached :avatar_with_lazy_variants do |attachable|
  attachable.variant :lazy_thumb, resize_to_limit: [3, 3], process: :lazy
  attachable.variant :default_thumb, resize_to_limit: [4, 4]
end

has_one_attached :avatar_with_later_variants do |attachable|
  attachable.variant :later_thumb, resize_to_limit: [2, 2], process: :later
end

has_one_attached :avatar_with_immediate_variants do |attachable|
  attachable.variant :immediate_thumb, resize_to_limit: [1, 1], process: :immediately
end
```

* Active Storage: make Variant#processed? and VariantWithRecord#processed? public

Apps can now check whether variants have been generated. Useful for
precise control of variant usage or generation.

Co-authored-by: Tom Rossi <tomrossi7@users.noreply.github.com>

* Deprecate `preprocessed: true` in favor of `process: :later`

For removal in Rails 9.0.

Co-authored-by: Tom Rossi <tomrossi7@users.noreply.github.com>

* Document immediate variants: guide and changelog

Co-authored-by: Tom Rossi <tomrossi7@users.noreply.github.com>

* Making ActiveStorage::Preview#processed? a public method

Removing space

* Use consistent naming for transformations parameter (#7)

ActiveStorage uses the plural `transformations` for a single hash of transformation options (e.g., `{ resize_to_limit: [100, 100] }`).

To differentiate between a single transformation hash and an array of transformation hashes, this commit introduces `transformations_array` for arrays of transformations, while retaining transformations for individual hashes.

* Fixing changelog

* Rename transformations_array to variants

Aligns with `CreateVariantsJob` naming and `ActiveStorage` terminology
where variants represent the result of transformations applied to
the original blob.

Fixing create_preview_image

---------

Co-authored-by: Jeremy Daer <jeremy@rubyonrails.org>
Co-authored-by: Tom Rossi <tomrossi7@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants