Skip to content

Feature 59 ajax for project table#108

Merged
DarianGill merged 7 commits into
developfrom
feature-59-ajax-for-project-table
Dec 2, 2025
Merged

Feature 59 ajax for project table#108
DarianGill merged 7 commits into
developfrom
feature-59-ajax-for-project-table

Conversation

@DarianGill

Copy link
Copy Markdown
Collaborator

What:
Closes #59 by implementing dataTablesAjax server-side search and paging functionality to the project table. Also standardizes some date formatting for the detail and table views and truncates the description column text in the table.

Why:
To further minimize the data stored in the shiny server session and align with the approach taken for concept tables.

How:

  • Removed the cached project rds file and server.R logic that read it
  • Created a spec constant and helper functions to generate the project table configuration
  • Added helper functions in table_project.R to coerce party pages returned by vegbankr into dataframes (For parity with concepts where this is necessary because of nested lists of dataframes) and normalize party data
  • Added TODO and Add list of contributing parties to project details #107 to track work adding project contributors to the detail view when cross resource requests are supported

Docs and Testing:

Updated project table tests to enforce new configuration and test processing function normalizes rows
All tests pass and devtools::check() runs with only a warning about using unexported get_all_resources from vegbankr

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Pull request overview

This PR implements server-side AJAX data loading for the project table, removing the dependency on cached project data and standardizing date formatting across the application.

Key Changes:

  • Migrated project table from client-side rendering with cached data to server-side AJAX pagination
  • Introduced format_date helper function to standardize date formatting across detail and table views
  • Added data normalization and coercion functions (normalize_project_data, coerce_project_page) to handle API responses

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 4 comments.

Show a summary per file
File Description
tests/testthat/test_project_table.R Updated tests to validate AJAX configuration and data processing pipeline instead of cached data handling
R/table_project.R Complete refactor to implement remote data loading with normalization, coercion, and display transformation functions
R/table.R Added clean_column_dates helper function for consistent date formatting in table columns
R/server.R Removed cached project data loading logic and updated table render call to use parameterless AJAX approach
R/detail_reference.R Refactored to use new format_date helper for date formatting consistency
R/detail_project.R Standardized date field formatting using format_date helper across all date columns
R/detail_helpers.R Added new format_date helper that wraps safe_parse_date and handles formatting with default fallback

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment thread tests/testthat/test_project_table.R
Comment thread R/table_project.R
Comment thread R/table.R Outdated
Comment thread R/table_project.R
@DarianGill DarianGill marked this pull request as ready for review December 2, 2025 00:34
@DarianGill DarianGill requested a review from regetz December 2, 2025 00:34

@regetz regetz left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Nice, one more table done, thanks! I added a few comments, but nothing big, and two of them are about future to-dos anyway.

Comment thread R/detail_project.R
project_description = shiny::renderUI({
htmltools::tags$div(id = "project-description", htmltools::HTML(result$project_description))
}),
# TODO: Implement contributor listing when API supports cross-resource queries

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Or, just a thought, we could add a relevant nested field to the data returned by the parties endpoint. I mean, I kinda prefer to keep the API simpler and have clients just make the cross-resource request as needed, but we did already establish a precedent for the nested field. 🤷

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

@regetz I was actually gonna ask you if that was possible. I think it's the more parsimonious solution since we have the precedent of nested fields already.

Comment thread R/table.R
parsed
}

# TODO: Eventually should add a link to see details with full text at the end of truncated text

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

👍 Yeah I was thinking this too

Comment thread R/table_project.R
)
)
descriptions <- clean_column_data(project_data, "project_description")
descriptions <- truncate_text_with_ellipsis(descriptions, max_chars = 680L)

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Any reason why 680 characters, and not something shorter? Long descriptions make for some rather tall rows, and it's easy enough for users to click on the Details button to see the full description. Not a show-stopper to leave this as-is for now from my POV, but just throwing it out there in case you were thinking in the same direction.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

680 just happened to line up with the max height of a row to fit in the height of my screen. Pretty arbitrary and I'm definitely down to go smaller if that's your preference.

@DarianGill DarianGill merged commit 8155e34 into develop Dec 2, 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.

Add dataTablesAJAX processing to Project Table

3 participants