Use smarter type detection for AssignableTypes

[stevenleeg]

Hi there,

This PR stems from an issue I've asked about in Gitter but didn't end up with a response, so I figured I'd submit the fix myself.

When developing agents locally and importing them via the ADDITIONAL_GEMS=some_agent(path:../some_agent) pathway, I noticed that any agents within the gems wouldn't end up in the agents list of the agent creation page. Doing some digging, I found that the reason was that the dropdown was being populated, via various layers of the stack, by this line in assignable_types.rb:

const_set(:TYPES, Dir[Rails.root.join("app", "models", module_name.underscore, "*.rb")].map { |path| module_name + "::" + File.basename(path, ".rb").camelize })

Searching through the app/models/agents directory naturally omits agents provided by gems, as they're stored not only outside of that directory, but even outside of the Huginn project root. This PR fixes this by populating the TYPES constant with the actual list of constants contained by the namespace at runtime.

The one thing I'm a little stumped on is how this list ends up getting populated properly (ie including agens in gems) when in production, as this is an issue I've only been able to replicate on my development instance. Perhaps there's something I'm missing here, but otherwise this seems like a pretty straightforward fix.

[knu]

I'm afraid this may not work in development and test environments where files are lazy-loaded. Can you confirm this works even in development mode? (e.g. bundle exec rails r 'puts Agent::TYPES')

[admsev]

@gooroodev please take a look

[gooroodev]

Thanks, @admsev! Let's do this!

1. Summary of Changes

The pull request updates the method load_types_in within the AssignableTypes concern. The original implementation used file path detection to determine the types. This has been replaced with a more intelligent method that uses module constants to detect types. Specifically:

• The old method collected types by reading file names from a directory.
• The new method collects types by inspecting the constants within the specified module and filtering them based on the module's singular name.

2. Issues, Bugs, or Typos

Issue 1: Potential Inaccuracy in Type Detection

The new type detection method filters constants based on whether their names include the singular name of the module. This could potentially miss some valid types or include irrelevant ones if the naming convention is not strictly followed.

Improvement Proposal:
Instead of using include?, consider using a more precise matching strategy, such as checking if the constant's name starts with or ends with the singular name.

types = module_name.constantize.constants
  .select { |t| t.to_s.start_with?(my_name) || t.to_s.end_with?(my_name) }
  .map { |t| "#{module_name}::#{t}" }

Issue 2: Missing Newline at End of File

The file is missing a newline at the end, which is a common convention in many coding standards.

Improvement Proposal:
Add a newline at the end of the file to adhere to coding standards.

3. General Review of Code Quality and Style

Code Quality

• The new method for type detection is more dynamic and reduces dependency on file paths, which is a positive change.
• The code is more maintainable as it relies on the module's constants rather than the file system structure.

Code Style

• The use of select and map is appropriate and follows Ruby conventions.
• Indentation and spacing are consistent and readable.

Potential Improvements

• Documentation: Adding comments to explain the logic behind type detection would improve code readability and maintainability.
• Error Handling: Consider adding error handling to manage cases where module_name.constantize might fail or return unexpected results.

Conclusion

The pull request introduces a more dynamic approach to type detection, which is a positive change. Addressing the potential inaccuracy in detection and adding a newline at the end of the file will further improve the quality of the code.

Yours, Gooroo.dev. Got thoughts? Don't hesitate to reply or add a reaction.