Skip to content

Instantly share code, notes, and snippets.

@kaspth
Created August 16, 2023 17:35
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save kaspth/10291b67cf4872a25d1dbdeb1bde03d3 to your computer and use it in GitHub Desktop.
Save kaspth/10291b67cf4872a25d1dbdeb1bde03d3 to your computer and use it in GitHub Desktop.

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.

PRs

  • 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 to register User where we'll automatically tableize 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 take ActiveRecord::Base.connection.tables and automatically register 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 for users.with to set default and derivable attributes. Check the PR for the comment on our bananas Struct use.
  • #19 following up on that, I added an extra test, I remembered as soon as I merged #18.

Up Next

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.

Contributions

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.

How's it working for you so far?

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?

@kaspth
Copy link
Author

kaspth commented Aug 16, 2023

It looks better in the repo where GitHub enriches the PR links with their titles too:

Screenshot 2023-08-16 at 20 04 38

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment