Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tidy the CSS parser API #3218

Closed
wants to merge 7 commits into from
Closed

Conversation

flavorjones
Copy link
Member

@flavorjones flavorjones commented Jun 6, 2024

What problem is this PR intended to solve?

In preparation for #2560's work to introduce a new CSS selector parser, I want to take the opportunity to clean some things up, including the awkward cache API that I wrote in (gulp) 2008.

None of this should be considered a breaking change, since the CSS::Parser and related classes are undocumented and considered internal-only (with the notable exception of CSS::XPathVisitor).

Big changes in this PR:

  • CSS parser caching is extracted into CSS::SelectorCache
  • CSS.xpath_for takes a cache: kwarg and this is where the caching is done (not in the Parser)
  • Removed the awkward cache APIs CSS.set_cache, CSS.cache_on? and CSS.without_cache(&blk). Using the cache: argument to CSS.xpath_for should be sufficient and is in fact clearer code to write.
  • The prefix parameter for CSS-to-XPath transpilation is now pushed into the XPathVisitor class rather than being handled as an additional argument.
  • The CSS::Parser API has changed: the selector is now passed to .new and not #parse.

Smaller changes:

  • CSS.xpath_for deprecates the options hash and emits a warning. Users should prefer keyword arguments.
  • CSS.parse is deprecated and emits a warnings. (I will probably remove this in the parser rewrite since it returns an AST that is not supported.)
  • XPathVisitor exposes #prefix, #builtins, and #doctype attributes.
  • We avoid creating a namespaces hash unnecessarily in CSS.xpath_for.

@tenderlove I would love your eyeballs on this if you get a few minutes.

Have you included adequate test coverage?

Yes.

Does this change affect the behavior of either the C or the Java implementations?

No native behavior changes.

so that I can run them all with `-n/Nokogiri::CSS/` while I'm
developing the SyntaxTree integration.
Previously we've been handling it as a separate input to the
CSS.xpath_for method. This simplifies the code and the parser cache
key.
@flavorjones flavorjones force-pushed the flavorjones-tidy-the-css-parser-api branch from c6cb68d to e208053 Compare June 11, 2024 00:25
The global `Parser.set_cache` and `Parser.cache_on?` methods have been
removed, as has the `Parser.without_cache(&blk)` method.

The cache is now used by `CSS.xpath_for` (optionally, via a `cache:`
kwarg) instead of being part of the parser.

CSS::Parser has a different API which accepts the selector as a
parameter to the constructor (and `#parse` no longer takes an
argument). This is a prefactor for work to come.
@flavorjones flavorjones force-pushed the flavorjones-tidy-the-css-parser-api branch from e208053 to 35104b5 Compare June 11, 2024 00:41
@flavorjones
Copy link
Member Author

This PR is too big, and some of these changes I want to land in v1.17 and some may land in a later release. I'm going to break it up into smaller PRs.

@flavorjones flavorjones deleted the flavorjones-tidy-the-css-parser-api branch June 14, 2024 02:01
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