We've got a model User
, and we're adding in the ability for a user to share their actions on Facebook (and likely other social mediums later on). Obviously, not every user wants to do this, so we want to track their preferences on a per-action-type basis.
I figure there's four ways of handling this:
- Add a boolean column for every setting to the users table.
- Add a JSON hash column to the users table to store all preferences.
- Create a new model (
UserPreference
) and store each setting as a separate boolean column. - Create a new model (
UserPreference
) and perhaps have separate JSON hash columns per social medium (one for Facebook, one for Twitter, etc).
Whichever approach, it'd be really nice to have form objects for just preferences (and ones that handle situations where not all attributes/settings will be available - some users may only have Twitter connected, others only Facebook, etc).
I've currently gone with the second of the above options - a column called preferences
which can store each setting. I'm even tempted to have hashes within the hash, broken down by social medium.
# either
user.preferences #=> {'facebook_share_challenges' => true}
# or
user.preferences #=> {'facebook' => {'share_challenges' => true}}
I'm currently wondering if this is a good approach - maybe a column for each setting in a new model is better (option three) - works within normal conventions of Rails and Reform and other things. Hashes are certainly more flexible, but at what point does the mucking around to get things work become too much of a hassle?
Went down the path you've suggested, and what I'm finding is that
PreferencesForm
expectsUser::Preferences
to be an ActiveModel with theto_key
method.Here's the form object as it currently stands:
And the intermediate model:
Currently thinking I'll shift back to per-setting columns in a new model for preferences, just because it works more neatly with the Rails Way, even though I do prefer the more SRP/OO approach.