Feature #18594: Add a #to_h method on URI::Generic

• Status: Open
• Assignee: -
• Target version: -

[jimcavoli (Jim Cavoli)]

It's just surprisingly challenging to get a hash representation of a parsed URI where the keys are the component names and the values are the component values.

The shortest form I could come up with using only public methods on URI::Generic is rather clumsy-feeling:

uri = ::URI.parse(url)
hsh = [uri.component, uri.select(*uri.component)].transpose.to_h

Hence this suggested patch:

diff --git a/lib/uri/generic.rb b/lib/uri/generic.rb
index cfa0de6b74..f27a07a53c 100644
--- a/lib/uri/generic.rb
+++ b/lib/uri/generic.rb
@@ -1367,6 +1367,13 @@ def to_s
       str
     end

+    #
+    # Returns a Hash representing the URI components
+    #
+    def to_h
+      [component, component_ary].transpose.to_h
+    end
+
     #
     # Compares two URIs.
     #

Which would allow the much more ergonomic, idiomatic and terse usage:

uri = ::URI.parse(url)
hsh = uri.to_h

Also happy to put together tests/specs for that as required.

[Dan0042 (Daniel DeLorme)]

I'm not opposed, but what do you use the hash for? What's the use case? If it's for serialization, then normally you'd serialize the URI to a string and use URI parsing on the other side e.g. javascript (new URL(str)).path

[jimcavoli (Jim Cavoli)]

The use case I had that brought this up was actually around generating complex configuration files for another product from a simplified YAML config file, which involved extracting selected URI components to create a tokenized version for naming entities in the generated files. One key feature was the ability to override certain components used for the tokenizing process, and merging (compacted) hash representations was the simplest approach in that case to calculate the final values. Ultimately, it was not that big of a deal, as written above, to transpose an array of the components themselves, but just seemed like a path of more surprise than expected from a stdlib component.