Skip to content

docs: update README with hooks, shutdown, tracking, and hook development#228

Merged
josecolella merged 1 commit intomainfrom
chore/update-readme-post-compliance
Mar 5, 2026
Merged

docs: update README with hooks, shutdown, tracking, and hook development#228
josecolella merged 1 commit intomainfrom
chore/update-readme-post-compliance

Conversation

@josecolella
Copy link
Collaborator

Summary

Updates the README to reflect all spec compliance work completed in the recent sprint. Replaces "Coming Soon" placeholders with full documentation and code examples.

Changes

  • Features table: Hooks ⚠️→✅, Shutdown ⚠️→✅, Extending ⚠️→✅, added Tracking ✅ row
  • Hooks section: Full documentation with code examples for all 4 stages, registration at API/client/invocation levels
  • Shutdown section: Documents OpenFeature::SDK.shutdown and provider shutdown lifecycle
  • Tracking section: New section with usage examples (simple events, with context, with details)
  • Develop a hook: Full documentation replacing placeholder, shows Hook module usage
  • Provider duck type: Added optional track method to provider example

Test plan

  • No code changes — documentation only
  • bundle exec standardrb — no offenses

🤖 Jose's AI agent

- Update features table: Hooks ✅, Shutdown ✅, Extending ✅, add Tracking ✅
- Replace Hooks "Coming Soon" with full documentation and code examples
- Replace Shutdown "Coming Soon" with API.shutdown documentation
- Add Tracking section with usage examples per spec section 6
- Replace "Develop a hook" placeholder with Hook module documentation
- Add optional track method to provider duck type example

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Signed-off-by: Jose Colella <jose.colella@gusto.com>
@josecolella josecolella requested a review from a team as a code owner March 5, 2026 17:51
@josecolella josecolella merged commit a25d610 into main Mar 5, 2026
4 checks passed
@josecolella josecolella deleted the chore/update-readme-post-compliance branch March 5, 2026 17:53
@gemini-code-assist
Copy link

Summary of Changes

Hello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly enhances the documentation within the README.md file by replacing several 'Coming Soon' placeholders with detailed explanations and code examples. The updates cover the implementation of hooks, the shutdown process for providers, and the new tracking API, providing a more complete and up-to-date resource for developers using the OpenFeature Ruby SDK.

Highlights

  • Features Table Updated: The features table in the README has been updated to reflect the completion of Hooks, Shutdown, and Extending features (now marked with ✅), and a new row for Tracking (also marked with ✅) has been added.
  • Hooks Documentation Enhanced: The 'Hooks' section now includes comprehensive documentation with code examples for all four stages of hook execution and demonstrates registration at the API, client, and invocation levels, replacing the previous 'Coming Soon' placeholder.
  • Shutdown Process Documented: Detailed documentation for the OpenFeature::SDK.shutdown method and the provider shutdown lifecycle has been added, including code examples for both SDK-level shutdown and individual provider cleanup.
  • New Tracking Section Introduced: A new 'Tracking' section has been added, explaining how to associate user actions with feature flag evaluations using client.track, complete with examples for simple events, events with context, and events with detailed information.
  • Hook Development Guide Provided: The 'Develop a hook' section has been fully documented, replacing the placeholder, and now includes instructions and a code example for implementing custom hooks by including the OpenFeature::SDK::Hooks::Hook module.
  • Provider Duck Type Updated: The example provider duck type now includes an optional track method, aligning with the new tracking functionality and demonstrating how providers can support tracking events.
Changelog
  • README.md
    • Updated the features table to reflect completed features (Hooks, Shutdown, Extending) and added a new entry for Tracking.
    • Replaced 'Coming Soon' placeholder with full documentation and code examples for Hooks, including registration at global, client, and invocation levels.
    • Added detailed documentation for the SDK's shutdown method and how providers can implement their own shutdown logic.
    • Introduced a new section on Tracking, explaining its purpose and providing usage examples for various tracking scenarios.
    • Updated the 'Develop a hook' section with comprehensive guidance and a code example for creating custom hooks.
    • Modified the example provider duck type to include an optional track method, demonstrating support for tracking events.
Activity
  • The changes are purely documentation-related, with no functional code modifications.
  • The bundle exec standardrb command was executed, and no offenses were reported, indicating adherence to code style standards.
Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature Command Description
Code Review /gemini review Performs a code review for the current pull request in its current state.
Pull Request Summary /gemini summary Provides a summary of the current pull request in its current state.
Comment @gemini-code-assist Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help /gemini help Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

  1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution.

Copy link

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request provides a comprehensive update to the README, documenting several new features like hooks, shutdown, and tracking. The new sections are well-written with clear code examples. I have one minor suggestion to improve the hook registration example to promote a more efficient coding practice.

Note: Security Review has been skipped due to the limited scope of the PR.

Comment on lines +233 to +245
# Register at the API (global) level
OpenFeature::SDK.hooks << MyHook.new

# Register at the client level
client = OpenFeature::SDK.build_client
client.hooks << MyHook.new

<!-- TODO: code example of setting hooks at all levels -->
# Register at the invocation level
client.fetch_boolean_value(
flag_key: "my-flag",
default_value: false,
hooks: [MyHook.new]
)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

For stateless hooks like the example MyHook, it's more efficient and a better practice to instantiate the hook once and reuse the same object for all registrations. This avoids creating unnecessary objects and is a good pattern to demonstrate in documentation.

Suggested change
# Register at the API (global) level
OpenFeature::SDK.hooks << MyHook.new
# Register at the client level
client = OpenFeature::SDK.build_client
client.hooks << MyHook.new
<!-- TODO: code example of setting hooks at all levels -->
# Register at the invocation level
client.fetch_boolean_value(
flag_key: "my-flag",
default_value: false,
hooks: [MyHook.new]
)
# Instantiate the hook once
my_hook_instance = MyHook.new
# Register at the API (global) level
OpenFeature::SDK.hooks << my_hook_instance
# Register at the client level
client = OpenFeature::SDK.build_client
client.hooks << my_hook_instance
# Register at the invocation level
client.fetch_boolean_value(
flag_key: "my-flag",
default_value: false,
hooks: [my_hook_instance]
)

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant