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

fix timeline #171

Merged
merged 7 commits into from
Oct 30, 2024
Merged

fix timeline #171

merged 7 commits into from
Oct 30, 2024

Conversation

koilebeit
Copy link

@koilebeit koilebeit commented Oct 29, 2024

Pull request

Proposed changes

solves #165

Types of changes

  • New feature (non-breaking change which adds functionality).
  • Enhancement (non-breaking change which enhances functionality)
  • Bug Fix (non-breaking change which fixes an issue).
  • Breaking change (fix or feature that would cause existing functionality to change).

Checklist

  • I have read the CONTRIBUTING document.
  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.

Summary by CodeRabbit

  • New Features

    • Improved timeline layout with sorted year navigation and structured year display.
    • Enhanced sorting mechanism for date-related strings, providing detailed and structured output.
    • Introduced a method to filter items by year using regex for better data handling.
  • Bug Fixes

    • Corrected filtering of timeline entries to ensure accurate display based on year selection.

Copy link

changeset-bot bot commented Oct 29, 2024

⚠️ No Changeset found

Latest commit: 88d04e8

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

Copy link

coderabbitai bot commented Oct 29, 2024

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 @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

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.

📥 Commits

Files that changed from the base of the PR and between 67c1ef0 and 88d04e8.

Walkthrough

The changes introduced in this pull request involve significant updates to the _layouts/timeline_edtf.html, _plugins/sort_edtf.rb, and _plugins/jekyll_regex_match.rb files. The HTML layout now utilizes a new regex pattern for year matching and processes years in a sorted order for navigation and timeline entries. The sorting mechanism in the Ruby plugin has been enhanced to parse date strings into structured hashes, allowing for improved sorting and display formats. Additionally, a new method for filtering items by year has been added to the regex matching module.

Changes

File Change Summary
_layouts/timeline_edtf.html Updated regex for four-digit year matching, introduced sorted_years for navigation and content, modified dropdown for structured year links, and adjusted timeline entry generation to reflect sorted years.
_plugins/sort_edtf.rb Replaced previous sorting method with a new parsing mechanism that generates a hash for each string, including numeric representation and display format, and updated the method signature.
_plugins/jekyll_regex_match.rb Added new method filter_items_by_year to filter items based on a specified year and regex pattern, while existing methods remain unchanged.

Poem

In the garden of time, where years bloom bright,
Sorted and structured, a wonderful sight.
With links for each year, like carrots in rows,
The timeline now dances, as the soft breezes blow.
A hop and a skip, through the past we will run,
Celebrating the changes, oh what fun! 🐰✨


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?

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

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)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

Copy link

@coderabbitai coderabbitai bot left a 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:

  1. Add error handling for malformed year strings
  2. 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> &#8211;
-<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> &#8211;
+  <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> &#8211;
+  <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:

  1. Precomputing the year-item associations
  2. 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

📥 Commits

Files that changed from the base of the PR and between 7e7d40d and 1df0199.

📒 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

_plugins/sort_edtf.rb Show resolved Hide resolved
_plugins/sort_edtf.rb Show resolved Hide resolved
_plugins/sort_edtf.rb Outdated Show resolved Hide resolved
_plugins/sort_edtf.rb Outdated Show resolved Hide resolved
Copy link

@coderabbitai coderabbitai bot left a 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

📥 Commits

Files that changed from the base of the PR and between 1df0199 and 22cab12.

📒 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:

  1. 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)
  2. The filter is correctly registered with Liquid templating system
  3. 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

_plugins/sort_edtf.rb Outdated Show resolved Hide resolved
_layouts/timeline_edtf.html Outdated Show resolved Hide resolved
_layouts/timeline_edtf.html Outdated Show resolved Hide resolved
_layouts/timeline_edtf.html Outdated Show resolved Hide resolved
Copy link

@coderabbitai coderabbitai bot left a 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

📥 Commits

Files that changed from the base of the PR and between 22cab12 and 2c6ada5.

📒 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.

  1. The previous review comment about improving year filtering accuracy remains valid.
  2. 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 -%}

_layouts/timeline_edtf.html Show resolved Hide resolved
Copy link
Member

@maehr maehr left a 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)

Copy link

@coderabbitai coderabbitai bot left a 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:

  1. Nil input array
  2. 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

📥 Commits

Files that changed from the base of the PR and between 2c6ada5 and d4996c0.

📒 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:

  1. A dedicated EDTF sorting plugin that handles complex date formats
  2. A regex matching plugin with proper error handling
  3. 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

_plugins/jekyll_regex_match.rb Outdated Show resolved Hide resolved
_plugins/jekyll_regex_match.rb Outdated Show resolved Hide resolved
_plugins/jekyll_regex_match.rb Outdated Show resolved Hide resolved
_plugins/sort_edtf.rb Show resolved Hide resolved
_layouts/timeline_edtf.html Show resolved Hide resolved
Copy link

@coderabbitai coderabbitai bot left a 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

📥 Commits

Files that changed from the base of the PR and between d4996c0 and 67f971e.

📒 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)

_plugins/jekyll_regex_match.rb Show resolved Hide resolved
Copy link

@coderabbitai coderabbitai bot left a 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

📥 Commits

Files that changed from the base of the PR and between 67f971e and 67c1ef0.

📒 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)

_plugins/jekyll_regex_match.rb Show resolved Hide resolved
_plugins/jekyll_regex_match.rb Outdated Show resolved Hide resolved
_plugins/jekyll_regex_match.rb Outdated Show resolved Hide resolved
@koilebeit koilebeit requested a review from maehr October 30, 2024 15:01
Copy link
Member

@maehr maehr left a 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!

@maehr maehr merged commit 5f70da8 into Stadt-Geschichte-Basel:main Oct 30, 2024
2 checks passed
koilebeit added a commit that referenced this pull request Oct 30, 2024
@koilebeit koilebeit mentioned this pull request Oct 30, 2024
koilebeit added a commit that referenced this pull request Oct 30, 2024
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