-
Notifications
You must be signed in to change notification settings - Fork 3
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
fix timeline #171
fix timeline #171
Conversation
|
Warning Rate limit exceeded@koilebeit has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 4 minutes and 2 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. WalkthroughThe changes introduced in this pull request involve significant updates to the Changes
Poem
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: 4
🧹 Outside diff range and nitpick comments (4)
_layouts/timeline_edtf.html (3)
41-42
: Add error handling and improve accessibility.
While the year splitting logic works, consider these improvements:
- Add error handling for malformed year strings
- Enhance accessibility with ARIA labels
-{% assign year_parts = y | split: ':' %}
-<a class="dropdown-item" href="#y{{ year_parts[1] }}">{{ year_parts[0] }}</a>
+{% assign year_parts = y | split: ':' %}
+{% if year_parts.size == 2 %}
+ <a class="dropdown-item"
+ href="#y{{ year_parts[1] }}"
+ aria-label="Navigate to year {{ year_parts[0] }}"
+ >{{ year_parts[0] }}</a>
+{% else %}
+ <!-- Log error or handle invalid format -->
+ <a class="dropdown-item" href="#y{{ y }}">{{ y }}</a>
+{% endif %}
51-54
: Maintain consistent error handling with the navigation dropdown.
Apply the same error handling pattern here for consistency.
-{% assign first_year = sorted_years | first | split: ':' %}
-{% assign last_year = sorted_years | last | split: ':' %}
-<a href="#y{{ first_year[1] }}">{{ first_year[0] }}</a> –
-<a href="#y{{ last_year[1]}}">{{ last_year[0] }}</a>
+{% assign first_year = sorted_years | first | split: ':' %}
+{% assign last_year = sorted_years | last | split: ':' %}
+{% if first_year.size == 2 and last_year.size == 2 %}
+ <a href="#y{{ first_year[1] }}">{{ first_year[0] }}</a> –
+ <a href="#y{{ last_year[1]}}">{{ last_year[0] }}</a>
+{% else %}
+ <!-- Fallback to raw values -->
+ <a href="#y{{ sorted_years | first }}">{{ sorted_years | first }}</a> –
+ <a href="#y{{ sorted_years | last }}">{{ sorted_years | last }}</a>
+{% endif %}
59-67
: Consider performance optimization for large datasets.
The nested loops (years → items → figure generation) could impact performance with large datasets. Consider:
- Precomputing the year-item associations
- Implementing pagination or lazy loading for large timelines
Example optimization for year-item associations:
{% comment %}At the top of the file{% endcomment %}
{% assign year_items = {} %}
{% for item in items %}
{% assign year = item[field] | regex_match: regex | first %}
{% assign year_items[year] = year_items[year] | concat: item | uniq %}
{% endfor %}
{% comment %}In the timeline loop{% endcomment %}
{% assign inYear = year_items[year[1]] %}
_plugins/sort_edtf.rb (1)
17-21
: Ensure consistent display formatting and localization
The display format adds "v. Chr." for negative years but does not provide localization for other languages or formats. Consider abstracting the display logic to accommodate different locales or to consistently format all dates.
You might refactor the display logic:
display_format = if str.start_with?('-')
- "#{str[1..-1].sub(/^0+/, '')} v. Chr."
+ formatted_year = str[1..-1].sub(/^0+/, '')
+ "#{formatted_year} BCE"
else
- str.sub(/^0+/, '')
+ str.sub(/^0+/, '') + " CE"
end
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (2)
- _layouts/timeline_edtf.html (2 hunks)
- _plugins/sort_edtf.rb (1 hunks)
🔇 Additional comments (2)
_layouts/timeline_edtf.html (2)
23-24
: LGTM! Navigation year generation is improved.
The use of sorted_years ensures chronological order in the navigation points.
13-18
: Verify the regex pattern handles all EDTF date formats.
The new regex pattern [-]?[\dXx]{4,}
appears to handle basic EDTF year formats, but let's verify it covers all required cases.
✅ Verification successful
Based on the examination of the codebase, particularly the EDTF sort implementation and timeline templates, I can now provide a final response:
The regex pattern [-]?[\dXx]{4,}
correctly handles EDTF date formats used in the codebase
The implementation is verified to be correct because:
- The regex pattern matches the required EDTF date formats:
- Regular years (e.g., "1999")
- BCE years with minus sign (e.g., "-0999")
- Uncertain years with 'X' or 'x' (e.g., "19XX")
- The
sort_edtf
filter in_plugins/sort_edtf.rb
confirms these are the expected formats by:- Handling negative years (BCE) with the minus prefix
- Converting X/x to 0 for numeric comparison
- Properly formatting display values
- The timeline template uses this pattern to extract years from various date formats, including ranges (using '/') and approximate dates
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for any date formats in the metadata that might not match the regex
# Test: Search for date fields in the metadata
rg -A 1 "^date:" _data/
# Test: Search for any fields matching the timeline-field in theme config
if [ -f "_data/theme.yml" ]; then
timeline_field=$(yq e '.timeline-field' _data/theme.yml)
if [ ! -z "$timeline_field" ]; then
rg -A 1 "^$timeline_field:" _data/
fi
fi
Length of output: 202
Script:
#!/bin/bash
# Let's try a different approach to find sample data files and timeline configurations
# Find all yml/yaml/json files that might contain timeline data
echo "=== Looking for data files ==="
fd -e yml -e yaml -e json
# Check content of theme configuration if exists
echo -e "\n=== Checking theme configuration ==="
if [ -f "_config.yml" ]; then
cat "_config.yml"
fi
# Look for timeline-related liquid includes or layouts
echo -e "\n=== Checking timeline-related templates ==="
fd -e html -e liquid | grep -i "timeline"
# Search for date patterns in all data files
echo -e "\n=== Searching for date patterns in data files ==="
fd -e yml -e yaml -e json -x rg -l '[0-9]{4}|[-][0-9]{4}|[0-9]{4}[-][0-9]{2}|[Xx]{4}' {}
Length of output: 4258
Script:
#!/bin/bash
# Let's examine the actual date formats used in the codebase
# Check theme configuration for timeline settings
echo "=== Theme Configuration ==="
cat _data/theme.yml
# Check timeline templates for date handling
echo -e "\n=== Timeline Template Content ==="
cat _layouts/timeline.html
cat _layouts/timeline_edtf.html
# Look for any EDTF date examples in the codebase
echo -e "\n=== EDTF Date Patterns ==="
rg -A 1 '(date|year).*:.*[0-9XxuU\-\?~\/]' assets/data/
# Check if there are any custom filters for EDTF handling
echo -e "\n=== EDTF Filters ==="
fd -e rb | xargs rg -l "sort_edtf|edtf"
Length of output: 17699
Script:
#!/bin/bash
# Let's examine the EDTF filter implementation and check for actual date patterns
# Check the EDTF sort implementation
echo "=== EDTF Sort Implementation ==="
cat _plugins/sort_edtf.rb
# Look for date patterns with fixed regex
echo -e "\n=== Sample Date Patterns ==="
rg -A 1 "(date|year).*(:|=).*[0-9]" assets/data/
# Check if there are any example dates in metadata
echo -e "\n=== Metadata Date Examples ==="
if [ -f "_data/sgb-metadata.csv" ]; then
head -n 5 "_data/sgb-metadata.csv"
fi
Length of output: 2116
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: 4
🧹 Outside diff range and nitpick comments (1)
_layouts/timeline_edtf.html (1)
13-18
: Consider anchoring the year regex pattern.
The regex pattern '[-]?[\dXu]{4,}'
matches years well but could potentially match partial numbers within longer strings. Consider anchoring it:
-{% assign regex = '[-]?[\dXu]{4,}' %}
+{% assign regex = '^[-]?[\dXu]{4,}$' %}
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (2)
- _layouts/timeline_edtf.html (2 hunks)
- _plugins/sort_edtf.rb (1 hunks)
🧰 Additional context used
📓 Learnings (1)
_plugins/sort_edtf.rb (2)
Learnt from: koilebeit
PR: Stadt-Geschichte-Basel/forschung.stadtgeschichtebasel.ch#171
File: _plugins/sort_edtf.rb:35-35
Timestamp: 2024-10-29T10:29:13.216Z
Learning: In `_plugins/sort_edtf.rb`, converting EDTF dates to exact numerical values is intentional to enable sorting and rendering of the data.
Learnt from: koilebeit
PR: Stadt-Geschichte-Basel/forschung.stadtgeschichtebasel.ch#171
File: _plugins/sort_edtf.rb:31-38
Timestamp: 2024-10-29T10:30:35.563Z
Learning: Due to Liquid's limitations in handling complex structures like objects, concatenated strings are returned instead, such as in the `sort_edtf` method in `_plugins/sort_edtf.rb`.
🪛 rubocop
_plugins/sort_edtf.rb
[convention] 3-39: Perceived complexity for sort_edtf is too high. [10/8]
(Metrics/PerceivedComplexity)
🔇 Additional comments (4)
_plugins/sort_edtf.rb (2)
22-32
: LGTM! Well-structured display format handling
The display format logic is well-implemented with proper handling of BCE years and clean number formatting.
34-38
: LGTM! Sorting implementation respects Liquid constraints
The sorting logic is clean and efficient. While returning structured data would be ideal, the string concatenation approach is appropriate given Liquid's limitations in handling complex structures.
_layouts/timeline_edtf.html (2)
23-24
: LGTM: Navigation increment logic is well implemented.
The modulo operation correctly generates evenly spaced navigation points from the sorted years.
18-18
: Verify integration with sort_edtf filter.
The timeline now relies on the sort_edtf
filter for year sorting. Let's verify its implementation:
✅ Verification successful
The sort_edtf filter implementation is properly integrated with the timeline
The verification confirms that:
- The
sort_edtf
filter is properly implemented in_plugins/sort_edtf.rb
with robust handling of:- EDTF date formats including BCE dates (with minus prefix)
- Unknown digit placeholders (X/u)
- Leading zeros
- Human-readable display format ("v. Chr." for BCE dates)
- The filter is correctly registered with Liquid templating system
- The timeline layout (
timeline_edtf.html
) uses the filter appropriately to sort the years before generating navigation
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check the sort_edtf filter implementation
echo "Searching for sort_edtf filter definition..."
rg -l "sort_edtf" --type ruby
Length of output: 150
Script:
#!/bin/bash
# Let's examine the implementation of the sort_edtf filter
cat _plugins/sort_edtf.rb
Length of output: 1814
Script:
#!/bin/bash
# Let's check how this filter is being used in the timeline layout and other files
rg -A 5 "sort_edtf" --type html
Length of output: 547
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: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
- _layouts/timeline_edtf.html (2 hunks)
🔇 Additional comments (3)
_layouts/timeline_edtf.html (3)
41-47
: Error handling for year splitting still needs attention.
The previous review comment about adding error handling for year splitting remains valid and unaddressed.
55-60
: LGTM! Error handling has been properly implemented.
The changes properly implement the suggested error handling for year range generation.
65-73
: 🛠️ Refactor suggestion
Consider performance optimization for timeline generation.
- The previous review comment about improving year filtering accuracy remains valid.
- The nested loops for processing items within years could be optimized.
Consider pre-grouping items by year to avoid repeated filtering:
+{%- capture grouped_items -%}
+ {%- for item in items -%}
+ {%- assign item_year = item[field] | regex_match: regex | first -%}
+ {%- if item_year -%}
+ {{ item_year }}:{{ forloop.index }}{% unless forloop.last %};{% endunless %}
+ {%- endif -%}
+ {%- endfor -%}
+{%- endcapture -%}
+{%- assign year_groups = grouped_items | split: ';' | group_by_exp: "item", "item | split: ':' | first" -%}
Then use the grouped data in the timeline generation:
-{%- assign inYear = items | where_exp: 'item', 'item[field] contains year[1]' -%}
+{%- assign year_group = year_groups | where: "name", year[1] | first -%}
+{%- if year_group -%}
+ {%- assign item_indices = year_group.items | map: "split: ':' | last" -%}
+ {%- assign inYear = item_indices | map: 'to_integer' | map: 'minus: 1' | map: 'items[_]' -%}
+{%- endif -%}
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.
Thanks for the PR. Unfortunately it does not build.
Liquid Exception: Liquid error (line 13): Invalid date format: in /workspaces/forschung.stadtgeschichtebasel.ch/_layouts/timeline_edtf.html
------------------------------------------------
Jekyll 4.3.4 Please append `--trace` to the `build` command
for any additional information or backtrace.
------------------------------------------------
/workspaces/forschung.stadtgeschichtebasel.ch/_plugins/sort_edtf.rb:19:in `block in sort_edtf': Liquid error (line 13): Invalid date format: (Liquid::ArgumentError)
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: 5
🧹 Outside diff range and nitpick comments (3)
_plugins/jekyll_regex_match.rb (1)
24-24
: Add method documentation.
Please add YARD-style documentation to describe the method's purpose, parameters, return value, and usage example.
Add this documentation above the method:
# Filters an array of items based on whether their 'date' field contains a specific year
#
# @param items [Array<Hash>] Array of items with 'date' field
# @param year [String] Year to filter by
# @param regex_pattern [String] Regular expression pattern for matching dates
# @return [Array<Hash>] Filtered array of items
# @example
# items = [{'date' => '2023'}, {'date' => '2024'}]
# filter_items_by_year(items, '2023') #=> [{'date' => '2023'}]
_plugins/sort_edtf.rb (1)
3-6
: Add input validation for nil and non-string elements.
While empty string handling is good, consider adding validation for:
- Nil input array
- Non-string elements in the array
def sort_edtf(array_of_strings)
+ raise ArgumentError, "Input array cannot be nil" if array_of_strings.nil?
+ raise ArgumentError, "All elements must be strings" unless array_of_strings.all? { |e| e.is_a?(String) }
# Remove any empty strings after stripping whitespace
valid_dates = array_of_strings.reject { |str| str.strip.empty? }
🧰 Tools
🪛 rubocop
[convention] 3-43: Assignment Branch Condition size for sort_edtf is too high. [<13, 20, 10> 25.87/23]
(Metrics/AbcSize)
[convention] 3-43: Cyclomatic complexity for sort_edtf is too high. [8/7]
(Metrics/CyclomaticComplexity)
[convention] 3-43: Perceived complexity for sort_edtf is too high. [11/8]
(Metrics/PerceivedComplexity)
_layouts/timeline_edtf.html (1)
73-73
: Consider reusing the regex pattern.
The regex pattern '[-]?[\dXu]{4,}'
is duplicated. Consider using the already defined regex
variable to maintain consistency and follow the DRY principle.
-{%- assign inYear = items | filter_items_by_year: year[1], '[-]?[\dXu]{4,}' -%}
+{%- assign inYear = items | filter_items_by_year: year[1], regex -%}
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (3)
- _layouts/timeline_edtf.html (2 hunks)
- _plugins/jekyll_regex_match.rb (1 hunks)
- _plugins/sort_edtf.rb (1 hunks)
🧰 Additional context used
📓 Learnings (1)
_plugins/sort_edtf.rb (2)
Learnt from: koilebeit
PR: Stadt-Geschichte-Basel/forschung.stadtgeschichtebasel.ch#171
File: _plugins/sort_edtf.rb:35-35
Timestamp: 2024-10-29T10:29:13.216Z
Learning: In `_plugins/sort_edtf.rb`, converting EDTF dates to exact numerical values is intentional to enable sorting and rendering of the data.
Learnt from: koilebeit
PR: Stadt-Geschichte-Basel/forschung.stadtgeschichtebasel.ch#171
File: _plugins/sort_edtf.rb:31-38
Timestamp: 2024-10-29T10:30:35.563Z
Learning: Due to Liquid's limitations in handling complex structures like objects, concatenated strings are returned instead, such as in the `sort_edtf` method in `_plugins/sort_edtf.rb`.
🪛 rubocop
_plugins/sort_edtf.rb
[convention] 3-43: Assignment Branch Condition size for sort_edtf is too high. [<13, 20, 10> 25.87/23]
(Metrics/AbcSize)
[convention] 3-43: Cyclomatic complexity for sort_edtf is too high. [8/7]
(Metrics/CyclomaticComplexity)
[convention] 3-43: Perceived complexity for sort_edtf is too high. [11/8]
(Metrics/PerceivedComplexity)
🔇 Additional comments (4)
_plugins/sort_edtf.rb (1)
38-42
: LGTM! Sorting and output formatting look good.
The implementation correctly:
- Sorts dates by their numeric representation
- Returns concatenated strings as required by Liquid's limitations
_layouts/timeline_edtf.html (3)
41-47
: LGTM! Proper error handling implemented.
The code now correctly handles malformed year data by checking the size of year_parts before accessing the elements.
55-60
: LGTM! Robust error handling for year range display.
The code properly validates year parts before rendering, preventing potential errors with malformed data.
Line range hint 13-73
: Verify date format handling across the dataset.
Let's ensure that the new date handling logic works with all existing date formats in the dataset.
✅ Verification successful
Based on the examination of the code, I can now provide a final response:
Timeline date handling implementation is robust and handles various date formats correctly
The implementation correctly handles:
- Standard year formats (e.g., "1900")
- Negative years (BCE dates) with proper display as "v. Chr."
- Years with uncertainty markers (X/u) by converting them to zeros for sorting
- Leading zeros in dates
- Multiple date formats through regex pattern
[-]?[\dXu]{4,}
The changes in the timeline implementation are well-supported by:
- A dedicated EDTF sorting plugin that handles complex date formats
- A regex matching plugin with proper error handling
- Consistent date extraction and filtering across the implementation
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for date formats that might not be handled by the current implementation
# Test: Search for date patterns in the metadata
echo "Checking unique date formats in the dataset..."
fd -e yml -e yaml -e json . _data/ -x cat {} \; | rg -o '"date":\s*"([^"]+)"' -r '$1' | sort -u
# Test: Look for potential EDTF features in use
echo "Checking for EDTF features..."
fd -e yml -e yaml -e json . _data/ -x cat {} \; | rg -o '"date":\s*"([^"]+)"' -r '$1' | rg -c '[?~]|\.\.|2[1-4]'
Length of output: 390
Script:
#!/bin/bash
# Let's try a different approach to find date patterns in the repository
# Look for sample data files
echo "Finding data files..."
fd -e yml -e yaml -e json . _data/
# Check content of theme configuration for date-related settings
echo -e "\nChecking theme configuration..."
fd -g "*theme*.yml" -g "*theme*.yaml" . -x cat {}
# Look for timeline-related templates
echo -e "\nChecking timeline templates..."
fd -g "*time*.html" . -x cat {}
# Look for date-related filters or plugins
echo -e "\nChecking for date handling code..."
fd . -e rb -e liquid --exec grep -l "date\|time" {} \;
Length of output: 21489
Script:
#!/bin/bash
# Let's examine the date handling plugins and their functionality
# Check the EDTF sorting plugin
echo "Examining EDTF sorting plugin..."
cat ./_plugins/sort_edtf.rb
# Check the regex matching plugin
echo -e "\nExamining regex matching plugin..."
cat ./_plugins/jekyll_regex_match.rb
# Look for sample metadata to understand date formats
echo -e "\nLooking for sample metadata..."
fd -g "*sample*.csv" -g "*sample*.json" . -x cat {}
Length of output: 3322
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: 1
🧹 Outside diff range and nitpick comments (2)
_plugins/jekyll_regex_match.rb (2)
23-24
: Fix indentation to match file style.
The indentation here doesn't match the rest of the file's style (8 spaces vs 4 spaces).
- def filter_items_by_year(items, year, regex_pattern = '[-]?[\dXu]{4,}')
+ def filter_items_by_year(items, year, regex_pattern = '[-]?[\dXu]{4,}')
34-36
: Remove unused exception variable.
The exception variable e
is declared but never used.
- rescue RegexpError => e
+ rescue RegexpError
🧰 Tools
🪛 rubocop
[warning] 34-34: Useless assignment to variable - e
.
(Lint/UselessAssignment)
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
- _plugins/jekyll_regex_match.rb (1 hunks)
🧰 Additional context used
🪛 rubocop
_plugins/jekyll_regex_match.rb
[convention] 24-38: Cyclomatic complexity for filter_items_by_year is too high. [10/7]
(Metrics/CyclomaticComplexity)
[convention] 24-38: Perceived complexity for filter_items_by_year is too high. [10/8]
(Metrics/PerceivedComplexity)
[warning] 34-34: Useless assignment to variable - e
.
(Lint/UselessAssignment)
🔇 Additional comments (1)
_plugins/jekyll_regex_match.rb (1)
24-38
: LGTM! Complexity is justified.
While static analysis flags high complexity, the implementation is well-structured and necessary for robust input validation, error handling, and performance optimization. The complexity comes from:
- Regex pattern validation
- Input type checking
- Caching mechanism
- Error handling
These are all essential for a reliable implementation.
🧰 Tools
🪛 rubocop
[convention] 24-38: Cyclomatic complexity for filter_items_by_year is too high. [10/7]
(Metrics/CyclomaticComplexity)
[convention] 24-38: Perceived complexity for filter_items_by_year is too high. [10/8]
(Metrics/PerceivedComplexity)
[warning] 34-34: Useless assignment to variable - e
.
(Lint/UselessAssignment)
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
🧹 Outside diff range and nitpick comments (1)
_plugins/jekyll_regex_match.rb (1)
24-26
: Consider additional parameter validation.
While the current validation is good, consider adding these checks:
- Validate that
year
matches the expected format - Ensure
regex_pattern
contains valid regex characters
def filter_items_by_year(items, year, regex_pattern = '[-]?[\dXu]{4,}')
raise ArgumentError, 'Regex pattern too complex' if regex_pattern.length > 50
+ raise ArgumentError, 'Invalid year format' unless year.to_s.match?(/^[-]?\d{4}$/)
+ raise ArgumentError, 'Invalid regex pattern' unless regex_pattern.match?(/^[\[\]\-\?\+\*\{\}\(\)\|\.\^\$\w\\]+$/)
return [] unless items.is_a?(Array) && !year.nil?
🧰 Tools
🪛 rubocop
[convention] 24-50: Assignment Branch Condition size for filter_items_by_year is too high. [<10, 18, 16> 26.08/23]
(Metrics/AbcSize)
[convention] 24-50: Cyclomatic complexity for filter_items_by_year is too high. [15/7]
(Metrics/CyclomaticComplexity)
[convention] 24-50: Perceived complexity for filter_items_by_year is too high. [15/8]
(Metrics/PerceivedComplexity)
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
- _plugins/jekyll_regex_match.rb (1 hunks)
🧰 Additional context used
🪛 rubocop
_plugins/jekyll_regex_match.rb
[convention] 24-50: Assignment Branch Condition size for filter_items_by_year is too high. [<10, 18, 16> 26.08/23]
(Metrics/AbcSize)
[convention] 24-50: Cyclomatic complexity for filter_items_by_year is too high. [15/7]
(Metrics/CyclomaticComplexity)
[convention] 24-50: Perceived complexity for filter_items_by_year is too high. [15/8]
(Metrics/PerceivedComplexity)
[warning] 46-46: Useless assignment to variable - e
.
(Lint/UselessAssignment)
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.
Thanks again. It seems to work perfectly!
This reverts commit 5f70da8.
Pull request
Proposed changes
solves #165
Types of changes
Checklist
Summary by CodeRabbit
New Features
Bug Fixes