* Remove channels from default app/ structure
Now that Hotwire is the default, the majority of apps won't need custom
channels. And those that do can get the files back via the generator.
* Remove trailing space
* Remove additional needless elements
* No longer to be generated
* No longer generated
Add a new script default folder to hold one-off or general purpose
scripts, such as data migration scripts, cleanup scripts, etc. Also add
a script generator to create such scripts.
Co-authored-by: Haroon Ahmed <haroon.ahmed25@gmail.com>
Noticed when reading the edge guides that we have some wonky formatting for the case when we use a method name in an h2 heading.
There's already a fix for h3-level headings, so I copied the font-weight (400) and eyeballed a font-size. 2.25rem looked too much to my eyes, so went with 2rem.
For accessibility reasons[1], it's recommended not to use "here"/"click
here"/"more" as the title for a link. When screen reader users are
tabbing through all links on the page, they'll miss the context of "read
more about X" preceding the "here". Thankfully, the sentences in the are
largely good to go, so the "here" can be dropped in favour of the last
part of the sentence to give the link title more meaning.
Some of these text changes may seem trivial, but when considering the
link text outwith its context sentences, the text has some more meaning
for those reading them through screen readers. (e.g. "API documentation"
-> "`number_to_currency` API documentation")
[1]: https://www.gov.uk/guidance/content-design/links#writing-link-text
In addition to updating the code examples and editing text for clarity and flow, here some more details on some of the changes:
- [X] Do we still need an HTML5 warning at the end of the 1st section? It's pretty standard these days.
--> agree, removed.
- [X] Not sure the output of `_form_with model: @article`_ is 100% correct, might need to double check that.
--> yes. updated this example and got the HTML output from my "guides playground" rails app.
- [X] When we mention `record.persisted?` in record identification, could be a good plug to link to the Active Model guide on that.
--> Hm...there is no direction mention, other than this https://guides.rubyonrails.org/active_model_basics.html#conversion
- [X] Similar to STI, link to the guide / reference on it.
- [X] Time Zone and Country Select should likely be broken into separate sub-sections (I don't mind still mentioning country select)
- [X] Would the file upload example would be better with a CSV for local processing, rather than showing saving to local disk? (which is probably a very uncommon usage?)
- [X] The _labeled_form_with_ example could likely be simplified with `_**options_` being all that it takes, instead of explicitly showing all possible kwargs.
- [X] It may be better to show "complex forms" (section 10) right after the parameters (section 8), moving "forms to external resources" down... just because complex forms require exactly the fields_for incantation that was detailed further under the parameters section, so it seems a better continuation. (or potentially even reversed? complex forms then params? not sure)
- [X] Under "complex forms", adding fields on the flow could be slightly expanded, it feels very "go figure".
--> Yeah, not sure what to do about this one. Was thinking about removing it as there is not built-in support to showcase.
---------
Co-authored-by: Ridhwana <Ridhwana.Khan16@gmail.com>
Co-authored-by: Petrik de Heus <petrik@deheus.net>
Co-authored-by: Amanda Perino <58528404+AmandaPerino@users.noreply.github.com>
Co-authored-by: Karl Lingiah <karl@superchilled.co.uk>
Rails 7 apps require running in `zeitwerk` mode, so we no longer need
the migration guide. The "Autoloading and Reloading Constants" guide
also handles autoloading with Zeitwerk, including `autoload_paths`, the
`zeitwerk:check` command and more.
- [x] We talk about transactions and how to disable them early on, as part of the first few paragraphs, that could be a subsection to add separation.
- [x] The guide goes into reversible early, before even talking about generating migrations and other basic stuff, and then later talks more about it. I think it's important to lay the foundation of change vs up/down, and the fact that migrations should always try to be able to be rolled back, but maybe we can do that without going into reversible that early in the guide, which complicates things further.
- [x] We mention bin/rails generate --help to look for more details, but we could mention specific generators also offer help too, e.g. bin/rails generate model --help or bin/rails generate migration --help
- [x] There's a small section about composite PKs, but there's also [a whole guide on it](https://edgeguides.rubyonrails.org/active_record_composite_primary_keys.html), we can add a link to it from the migrations guide at least for more info on the topic.
- [x] The section that talks about execute shows an example of a specific model Product.connection.execute, but we can call execute directly within a migration, that might be simpler to show.
- [x] We talk about "seed data " in setup & preparing sections, but never mention it before, or explain what seed data is. There's a section about seed data later in the guide, perhaps we can link to it to facilitate.
- [x] In "running specific migrations", bin/rails db:migrate VERSION=zomg actually raises a different error: Invalid format of target version: `VERSION=zomg`... might need a different example there for the unknown migration version error. (no need to show this invalid format one)
- [x] The section about referential integrity can likely be better explained, in particular I think it's worth mentioning that even though the "AR method/way" (the pattern, I mean) doesn't think such "intelligence" belongs to the database, foreign keys and unique indexes are generally safer at the database level. (and should likely have their counterparts explicitly added in code with associations and validations). I just don't want to convey that someone shouldn't be adding FKs & unique constraints, because not adding these can definitely bite you.
Other changes:
- [x] Moved sections around
- [x] Added a section about "Rails Migration Version Control"
- [x] Added a section about "Using UUIDs instead of IDs for Primary Keys"
Co-authored-by: bhumi1102 <bhumi1102@gmail.com>
Co-authored-by: Bartosz Łęcki <bart.lecki@gmail.com>
Co-authored-by: Cecile Veneziani <cveneziani@users.noreply.github.com>
Co-authored-by: hatsu <hajiwata0308@gmail.com>
Co-authored-by: Petrik de Heus <petrik@deheus.net>
Co-authored-by: Ahmad hamza <ahmad.hamza@toptal.com>
Co-authored-by: Bart de Water <496367+bdewater@users.noreply.github.com>
Co-authored-by: Amanda Perino <58528404+AmandaPerino@users.noreply.github.com>
Co-authored-by: Andy Atkinson <andyatkinson@gmail.com>
Co-authored-by: Jamie Gaskins <jgaskins@gmail.com>
Follow up to [#50527][]
Highlight the presence of the `yield :head` pattern established by
`turbo-rails` and adopted by Rails as part of [#50527][].
New applications will generate their application layout with `yield
:head`, so mention that in the documentation.
Also include the `yield :head` call in generated plugin layouts.
[#50527]: https://github.com/rails/rails/pull/50527
Review and improve Action View Overview guide. [ci-skip]
* Samples that use Proc.new {} can likely be simplified to just use proc {}
* Link to the validations guide where we mention it under conditional callbacks
* after_find callbacks are also triggered by a few other methods: take, sole, find_by!
* We could potentially add some more examples on different types of callbacks that aren't there.
* Updated some sections for clarity
Co-authored-by: Petrik de Heus <petrik@deheus.net>
Co-authored-by: Carlos Antonio da Silva <carlosantoniodasilva@gmail.com>
Co-authored-by: hatsu <hajiwata0308@gmail.com>
Improve RTL language support, specifically focused on Arabic (MSA), Farsi, and Hebrew languages, including custom fonts for those languages, a javascript to detect auto-translation and shift the dir attribute, and other cleanup based on volunteer feedback.
Co-authored-by: Carlos Antonio da Silva <carlosantoniodasilva@gmail.com>
