-
Notifications
You must be signed in to change notification settings - Fork 0
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
tricky support for container styles #37
Conversation
WalkthroughThe pull request includes updates to multiple Changes
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 6
🧹 Outside diff range comments (1)
respo/Cargo.toml (1)
Line range hint
31-54
: Consistent web-sys feature setThe web-sys features list is comprehensive and matches the requirements for DOM manipulation. However, as noted in the demo_respo review, consider adding container query related features.
Consider adding the following web-sys features for container query support:
- "CssContainerRule"
- "CssContainerStyleSheet"
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
⛔ Files ignored due to path filters (1)
Cargo.lock
is excluded by!**/*.lock
📒 Files selected for processing (5)
demo_respo/Cargo.toml
(1 hunks)demo_respo/src/main.rs
(3 hunks)respo/Cargo.toml
(3 hunks)respo/src/node/css.rs
(2 hunks)respo_state_derive/Cargo.toml
(1 hunks)
🔇 Additional comments (4)
respo_state_derive/Cargo.toml (1)
Line range hint 14-19
: Verify syn upgrade compatibility
The update from syn 2.0.77 to 2.0.90 is a minor version bump. While this should be backward compatible, it's good practice to verify the changelog for any potential breaking changes in proc-macro behavior.
✅ Verification successful
Syn upgrade is safe to proceed
The proc macro implementation uses only basic syn functionality (parsing and accessing identifiers) that has been stable across 2.0.x versions. The implementation is straightforward and doesn't rely on any advanced syn features that might be affected by version changes:
- Only uses
syn::parse()
for basic TokenStream parsing - Only accesses the
ident
field ofDeriveInput
- No custom parsers or complex syn API usage
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check syn changelog for breaking changes between 2.0.77 and 2.0.90
# Fetch the changelog from syn repository
gh api repos/dtolnay/syn/contents/CHANGELOG.md | jq -r '.content' | base64 -d | grep -A 10 "2.0.90\|2.0.77"
Length of output: 229
Script:
#!/bin/bash
# Let's verify if there are any changes in the codebase that might be affected by the syn upgrade
# Look for any proc macro implementations that might be sensitive to syn changes
# Search for proc macro attribute usage
ast-grep --pattern 'proc_macro'
# Also check for any direct syn API usage
rg "syn::" -A 2
Length of output: 512
Script:
#!/bin/bash
# Let's examine the actual proc macro implementation to understand syn usage
cat respo_state_derive/src/lib.rs
Length of output: 1149
demo_respo/Cargo.toml (2)
20-21
: Verify uuid compatibility
The uuid update from 1.10.0 to 1.11.0 appears safe as it maintains the same feature set ("v4", "js").
Line range hint 26-45
: Verify web-sys features for container queries
The web-sys update to 0.3.76 aligns with the PR's container styles objective. However, we should verify if additional features are needed for CSS container query support.
Consider adding the following web-sys features if you plan to use container queries:
- "CssContainerRule"
- "CssContainerStyleSheet"
respo/Cargo.toml (1)
3-3
: Version bump aligns with feature addition
The increment to version 0.1.15 is appropriate for adding container styles support.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 2
🧹 Outside diff range comments (1)
respo/src/node/css.rs (1)
Container queries implementation needs runtime checks and documentation
The implementation currently lacks browser compatibility checks and documentation for container query support. Based on the codebase analysis:
- No runtime checks exist to detect browser support for container queries
- No fallback mechanisms are implemented for unsupported browsers
- Documentation doesn't mention browser compatibility requirements
To address this:
- Add runtime detection using
window.CSS.supports('@container')
before applying container styles- Implement graceful fallbacks when container queries aren't supported
- Document browser requirements in the module's documentation
Example implementation to add:
// Before applying container styles, check: if window.CSS.supports("@container") { // Apply container styles } else { // Apply fallback styles }🔗 Analysis chain
Line range hint
739-931
: Verify browser compatibility for container queries.Container queries are a relatively new CSS feature. Consider:
- Adding browser compatibility checks
- Implementing fallback styles for unsupported browsers
- Documenting browser support requirements
Run the following script to check browser support:
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check MDN data for container query browser support curl -s "https://raw.githubusercontent.com/mdn/browser-compat-data/main/css/at-rules/container.json" | \ jq '.css.at-rules.container.support_data'Length of output: 265
Script:
#!/bin/bash # Let's check if there are any browser compatibility checks or fallbacks in the codebase rg -U "(?s)browser.*support|fallback|compat" --type rust # Also check if there's any documentation about browser requirements fd README -e md -X cat {} # Look for any error handling around container queries ast-grep --pattern 'container'Length of output: 11995
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
📒 Files selected for processing (2)
demo_respo/Cargo.toml
(1 hunks)respo/src/node/css.rs
(2 hunks)
🔇 Additional comments (4)
demo_respo/Cargo.toml (3)
17-17
: LGTM! Versions of js-sys and web-sys are properly synchronized.
The update maintains version synchronization between js-sys and web-sys (both at 0.3.76), which is important for compatibility.
Also applies to: 26-26
17-17
: Verify security implications of dependency updates.
Let's verify if the updated versions address any known vulnerabilities.
Also applies to: 20-20, 21-21, 22-22, 26-26
✅ Verification successful
No security vulnerabilities found in the updated dependencies
The GitHub Security Advisory Database shows no known vulnerabilities for any of the updated Rust dependencies (js-sys, uuid, serde, serde_json, web-sys). The dependency updates appear to be security-safe.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for security advisories for the updated dependencies
# Check for security advisories using GitHub API
for pkg in "js-sys" "uuid" "serde" "serde_json" "web-sys"; do
echo "Checking $pkg..."
gh api graphql -f query="
{
securityVulnerabilities(first: 5, ecosystem: RUST, package: \"$pkg\") {
nodes {
advisory {
summary
severity
publishedAt
}
vulnerableVersionRange
firstPatchedVersion {
identifier
}
}
}
}"
done
Length of output: 2391
Line range hint 28-47
: Consider adding CSS Container Query related features.
Given the PR's objective to support container styles and CSS @container rules, you might need to add features like "CssContainerRule" to the web-sys features list if they are available.
respo/src/node/css.rs (1)
744-787
: 🛠️ Refactor suggestion
Enhance error handling and performance.
The function has several areas for improvement:
- Replace
.expect()
calls with proper error handling - Use a string builder for better performance
- Add container query syntax validation
- Consider cleanup of old style tags
Consider this improved implementation:
-pub fn declare_contained_style<T, U>(name: T, rules: &[(Option<String>, U, RespoStyle)]) -> String
+pub fn declare_contained_style<T, U>(name: T, rules: &[(Option<String>, U, RespoStyle)]) -> Result<String, Box<dyn std::error::Error>>
where
T: Into<String> + Clone,
U: Into<String> + Clone + Display,
{
- let mut defined_styles = CLASS_NAME_IN_TAGS.write().expect("access styles");
+ let mut defined_styles = CLASS_NAME_IN_TAGS.write().map_err(|e| format!("Failed to access styles: {}", e))?;
if defined_styles.contains(&name.to_owned().into()) {
- name.into()
+ Ok(name.into())
} else {
- let window = web_sys::window().expect("window");
- let document = window.document().expect("load document");
+ let window = web_sys::window().ok_or("Failed to get window")?;
+ let document = window.document().ok_or("Failed to load document")?;
// ... similar changes for other expect calls
- let mut styles = String::from("");
+ let mut styles = String::with_capacity(rules.len() * 100); // Pre-allocate space
for (contained, query, properties) in rules {
+ if let Some(ref container) = contained {
+ // Validate container query syntax
+ if !container.starts_with("@container") {
+ return Err("Invalid container query syntax".into());
+ }
+ }
// ... rest of the implementation
}
- name.into()
+ Ok(name.into())
}
}
Likely invalid or redundant comment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Caution
Inline review comments failed to post. This is likely due to GitHub's limits when posting large numbers of comments.
Actionable comments posted: 1
🛑 Comments failed to post (1)
respo/src/node/css.rs (1)
842-888: 🧹 Nitpick (assertive)
Enhance documentation with browser compatibility notes
The macros are well-implemented with good examples, but consider adding browser compatibility information for container queries, as they are a relatively new CSS feature.
Add a note in the documentation:
/// macro to create a public function of CSS rules with a slice at current file scope, +/// Note: Container queries are supported in modern browsers (Chrome 105+, Firefox 110+, Safari 16+). +/// For compatibility information, see: https://caniuse.com/css-container-queries /// ```rust /// respo::contained_style_seq!(the_name,
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 3
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
⛔ Files ignored due to path filters (1)
Cargo.lock
is excluded by!**/*.lock
📒 Files selected for processing (3)
demo_respo/Cargo.toml
(1 hunks)respo/Cargo.toml
(3 hunks)respo/src/node/css.rs
(2 hunks)
🔇 Additional comments (4)
respo/src/node/css.rs (2)
837-840
: LGTM! Clean macro implementation.
The macro update properly handles trailing commas and maintains a clean delegation to static_style_seq
.
744-787
: 🛠️ Refactor suggestion
Consider improving error handling and performance.
The function has several areas that could be enhanced:
- Error handling uses
.expect()
which can panic. Consider using proper error propagation. - String concatenation in a loop could be inefficient for large style sets.
- Multiple DOM manipulations could be optimized.
Consider this refactoring:
-pub fn declare_contained_style<T, U>(name: T, rules: &[(Option<String>, U, RespoStyle)]) -> String
+pub fn declare_contained_style<T, U>(name: T, rules: &[(Option<String>, U, RespoStyle)]) -> Result<String, Box<dyn std::error::Error>>
where
T: Into<String> + Clone,
U: Into<String> + Clone + Display,
{
- let mut defined_styles = CLASS_NAME_IN_TAGS.write().expect("access styles");
+ let mut defined_styles = CLASS_NAME_IN_TAGS.write().map_err(|e| format!("Failed to access styles: {}", e))?;
if defined_styles.contains(&name.to_owned().into()) {
- name.into()
+ Ok(name.into())
} else {
- let window = web_sys::window().expect("window");
- let document = window.document().expect("load document");
+ let window = web_sys::window().ok_or("Failed to get window")?;
+ let document = window.document().ok_or("Failed to load document")?;
// ... similar changes for other expect calls
- let mut styles = String::from("");
+ let mut styles = String::with_capacity(rules.len() * 100); // Pre-allocate capacity
Likely invalid or redundant comment.
demo_respo/Cargo.toml (1)
17-17
: LGTM! Dependency versions are now consistent across workspace
The dependency versions have been properly aligned with the main respo
crate:
- js-sys 0.3.76
- serde 1.0.216
- serde_json 1.0.133
- web-sys 0.3.76
Let's verify the compatibility of these dependencies:
Also applies to: 20-22, 26-26
✅ Verification successful
Dependencies are properly aligned and compatible across workspace
Based on the Cargo.lock and dependency search results:
- All dependency versions are consistent between
demo_respo
andrespo
crates - No dependency conflicts or resolution issues in Cargo.lock
- Dependencies form a compatible set with wasm-bindgen 0.2.99
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify dependency compatibility and check for any reported issues
# Check for any compatibility issues or breaking changes in recent versions
gh api graphql -f query='
{
repository(owner: "rustwasm", name: "wasm-bindgen") {
releases(first: 5, orderBy: {field: CREATED_AT, direction: DESC}) {
nodes {
tagName
description
}
}
}
}'
# Check if there are any reported issues with these specific versions
rg -l "serde.*1\.0\.216|serde_json.*1\.0\.133|js-sys.*0\.3\.76" --type md
Length of output: 542
Script:
#!/bin/bash
# Let's verify the dependency compatibility in a different way
# Check Cargo.lock for any dependency conflicts
fd Cargo.lock --type f --exec cat {}
# Check if these versions are used consistently across workspace
rg "js-sys.*0\.3\." --type toml
rg "web-sys.*0\.3\." --type toml
rg "serde.*1\.0\." --type toml
rg "serde_json.*1\.0\." --type toml
Length of output: 10493
respo/Cargo.toml (1)
3-3
: Version bump aligns with the new container styles feature
The increment from 0.1.14 to 0.1.15 is appropriate for adding container styles support.
mainly for media query and https://developer.mozilla.org/en-US/docs/Web/CSS/@container
Summary by CodeRabbit
New Features
contained_styles!
for enhanced CSS styling.declare_contained_style
for inserting CSS styles with a contained selector.Bug Fixes
Documentation
Cargo.toml
files across packages.