This week we talk about dealing with complicated models, organizing large codebases, and taming stylesheets.
A weekly podcast about programming, development, and design through the lens of amazing books, chapter-by-chapter.
John: How / Why do they grow? Needs change:
John: All the different use cases for a user
"When you need to implement password recovery, and do not have a clear, single place to put the logic, it will still find its way into your code. It will spread itself across existing classes, usually making those classes harder to read and use.”
Example problem: Want to send a welcome email when a user is created via a public form but not when an admin creates a user via a backend interface
Core models should only have the absolute minimum to exist:
Core models should NOT have these things: (these things belong in multiple, interaction-specific form models)
virtual attributes that don't map 1:1 with db
callbacks to fire for a particular screen or use case (i.e. form signup)
we want the perks of AR models with AR. solution: inheritance
class User::AsSignUp < User
validates :password, presence: true, confirmation: true
private def send_welcome_email; end
John: Note the "AsSignup" pattern - "AsFacebookAuth"
class Invoice < ActiveRecord::Base has_many :items end class Item < ActiveRecord::Base belongs_to:invoice end
Why not just:
class Invoice::Item < ActiveRecord::Base belongs_to:invoice end
and move the file to:
The recommendations are a lot like BEM - A front-end development methodology - learn more at: http://getbem.com/
Abstracts (Sizing, Boarders, Spacing)Base (Grid, Colors, images, Typography)Components (Buttons, Cards, Alerts)Page Specific CSS