Skip to content

Conversation

@klnsv
Copy link
Contributor

@klnsv klnsv commented Nov 24, 2025

This PR refactors the render_html_list function to minmize the usage of unnecessary <ul> and <li> tags

I tried improving the UI but it messed up with the other components of the html page so I couldn't do much about it.

Please test it out extensively with different examples and let me know if anything breaks

Thanks!!!

@azimux
Copy link
Contributor

azimux commented Nov 24, 2025

oooo thank you! I'll spin up a rack connector for a super complex domain and poke around to see if anything looks bad

@klnsv
Copy link
Contributor Author

klnsv commented Nov 25, 2025

Please look at the above commit, which removes the functionality of skip_wrapper and hopefully produced a readable code.

Please check this with the script that you used yesterday

I am aware that there could be some edge cases.
Some of those edge cases:

  1. ::Array
  2. Manifest::Array
  3. Manifest::Type

@klnsv
Copy link
Contributor Author

klnsv commented Nov 25, 2025

Oof, Line coverage failed. Can I take care of that once we finalize the refactor?

@azimux
Copy link
Contributor

azimux commented Nov 25, 2025

Oof, Line coverage failed. Can I take care of that once we finalize the refactor?

Yeah that's always totally fine. Whatever order is fine for that kind of thing.

self.manifest = manifest
end

def render_html_list(data, skip_wrapper: false)
Copy link
Contributor

Choose a reason for hiding this comment

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

we probably don't need to rename the method unless it's doing something different than before and that the new name communicates what its doing from the outside. If we rename it but keep the method maybe #render_html is a better name for a public method that decouples it from _list.

def render_html_parent(data)
# This function is the parent function of render_html_list just to eliminate the skip_wrapper mechanism.
# This function eliminates the need to use <ul> tags in the render_html_list function calls.
# Note that we are making some calls on render_html_list function but eliminating the need for skip_wrapper.
Copy link
Contributor

Choose a reason for hiding this comment

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

We should probably put the comment on top of the method not inside it. Also we should call it "method" instead of "function" although in this case it might actually be more function-like.

Actually I'd be inclined to skip the comment. The skip_wrapper concept is gone so it's not helpful to mention it in a comment. If this is just a comment meant for PR review, the comment could just be made in the PR instead of in the code. Also, it mentions <ul> which is an implementation detail that could change at some point. Probably the easiest way in this case to be forward-compatible with various changes would be to delete the comment.

when ::Hash
html << "<ul>"
data.each do |key,value|
html << "<li>"
Copy link
Contributor

Choose a reason for hiding this comment

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

nice, yeah this helps I think

html
end

def render_html_list(data)
Copy link
Contributor

Choose a reason for hiding this comment

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

Hmmm I'm kind of surprised to see two methods. That feels like it sort of negates the benefit of removing a flag that controls behavior. I should compare the two methods to see how they differ but I'm nervous about splitting it into two methods instead of having a flag. I'll try to see what the differences are and see if there's something we can do to combine them into one method again but without the flag.

end

def render_html_list(data)
html = ""
Copy link
Contributor

Choose a reason for hiding this comment

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

something I think we need to start doing for Ruby 4 compatibility (I'm not 100% sure) is using the unary + operator for non-frozen string literals. So this should actually be html = +"" since we plan to mutate it. This happens in many places throughout the code though so it could be its own issue to find and fix these. But we may as well use the @+ operator whenever adding new code that wants a mutable string literal instead of a frozen string literal.

@azimux
Copy link
Contributor

azimux commented Nov 29, 2025

Closing in favor of #4

@azimux azimux closed this Nov 29, 2025
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.

2 participants