Here's the second weekly recap!
In last weeks recap, I shared where we were at in code and it looked like this:
# test_helper.rb
Oaken::Data.load_from "test/seeds"
# test/seeds/users.rb
User = Struct.new(:name, keyword_init: true)
memory.register :users, User # Uses the Oaken::Stored::Memory provider.
users.update :kasper, name: "Kasper"
# test/seeds/comments.rb
Comment = Struct.new(:name, keyword_init: true)
records.register :comments, Comment # Uses the Oaken::Stored::ActiveRecord provider.
# NOTE: this comments sample is mainly to demo `records` using a different provider.
But now we've got this:
# test_helper.rb
Oaken::Data.records.preregister ActiveRecord::Base.connection.tables.grep_v(/ar_/)
Oaken::Data.load_from "test/seeds"
# test/seeds.rb
accounts.with name: -> { id.to_s.humanize }
accounts.update :business, name: "Big Business Co." # We're overriding the `name` default here, but the default eases `accounts.update` calls in the tests.
# We're automatically deriving the `name` based off of `:kasper.to_s.capitalize`, and setting the `accounts` `has_many` `:through` which will create a `Membership` class under the hood.
users.with name: -> { id.to_s.capitalize }, accounts: [accounts.business]
users.update :kasper
users.update :coworker
Which I think is a really nice improvement! It also ends up satisfying the Up Next
part from last week's recap. It also feels good that the code itself is still just 115 lines.
- set us up with a section to add your names in #10, and did so in #15. If you want your name in the README too, please follow what #15 did and send your PR!
- In #11 by , our API changed from
register :users, User
toregister User
where we'll automaticallytableize
the class name.
Here's the stuff I worked on:
- I followed up on #11 in #12 to remove the Active Support dependency.
- #13 where we started removing the 1-1 model per Fixture file mapping and became more like seeds. So now we've got
test/seeds.rb
. - #14 we hooked up Active Record and closed out #5
- #16 also a follow up to #11 to extract out our internal inflection work and follow Zeitwerk's
inflector
extension pattern. - #17 when I set up Active Record in #14 I added a
preregister
method that'll takeActiveRecord::Base.connection.tables
and automaticallyregister
each of those. This refactors this a bit. Note: this may also go away soon, since I'm wondering if we should do this work lazily — and it's also not the best to support multiple databases. - #18 I set up a
has_many
through
association, and it just worked!!! I also added support forusers.with
to set default and derivable attributes. Check the PR for the comment on our bananasStruct
use. - #19 following up on that, I added an extra test, I remembered as soon as I merged #18.
Next week, I'd like to set up a geminabox
server on Heroku to host the gem so you can start using it in your apps. Have any of you worked with this before?
I've been meaning to do a write up on using GitHub better to follow along with this repo, and the tips are useful for building context in any repo.
brought up namespaces, e.g. what happens to register Post::Comment
, which I haven't really thought about yet. I'm going to be looking into having some sort of namespace conventions, maybe posts.comments.update :first, post: posts.first, subject: "My Insightful Critique, Vol. I", body: "In this Essay I will…"
I want to look at using upsert
in our Active Record calls (right now we're doing find_by
+ update
or create
), because that would let us cache the fixture files in SQL and be able to just seed the database with that. It's probably pretty tricky to do reliably, so this is going to be a relatively long process to figure out whether or not that's viable.
Setting up a Zoom/Whereby call to discuss where we're at, and hear your ideas. I'm curious if y'all are interested in doing a call? I could walk through the current codebase, and then we can see whatever else pops up. I'm thinking Thursday at 6pm UTC+2, that should cover most of the time zones we've got. How does that sound?
Kind of a packed week, this may be a bit too ambitious, so we'll see.
I'm hoping that getting the gem out so y'all can use it more will mean that the API is settled more so it'll make sense to start looking at README and documentation writing. I'm hopeful we can get to that during the week. I'll probably make an announcement with some documentation tips.
It seems like what's worked best for me for working on the code is to pick a few days in the week and then do some bursts of activity (and that may change as we go along), but how's that been for y'all to follow? Is it still relatively easy to follow along with what's been going on and be caught up? — are the recaps helpful in cutting through all that instead if the PRs are too much?
Anything you feel like is missing here, or that we should do differently? How do you like the code and how the API is looking so far?
It looks better in the repo where GitHub enriches the PR links with their titles too: