You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There is a suggestion that we should enable a feature to customize the html table rendering.
Describe the solution you'd like
Allow the user to set the amount of data returned. Right now it's hard coded to 2 MB. The actual data size is approximated. We would like this to be customizable.
Allow the user to disable the styling that is applied to the html output.
Optional: Add a way for a user to specify a formatting function to replace the default ArrayFormatter. This would enable users to change the data view when they have custom metadata
Nice to have: Split up some of the html generation into a set of helper functions.
Describe alternatives you've considered
None
Additional context
If this code is getting too large, it may make sense to split it off into a separate file.
The text was updated successfully, but these errors were encountered:
Modify the Data Size Limit
Identify the part of the code where the 2MB limit is enforced.
Introduce a user-configurable parameter (e.g., max_data_size), allowing users to set their preferred limit.
Ensure that the size approximation logic remains efficient and does not slow down performance.
Add an Option to Disable Styling
Locate the existing HTML rendering logic where styles are applied.
Introduce a flag (e.g., disable_styling) that allows users to enable or disable CSS styling in the output.
Implement a conditional check to apply styling only if the flag is not set.
Enable Custom Formatting
Modify the ArrayFormatter or introduce a parameter (e.g., custom_formatter) that allows users to pass their own formatting function.
Ensure that the custom function is validated and safely applied without breaking existing functionality.
Refactor HTML Generation Code (Nice-to-have for maintainability)
Break down the existing monolithic HTML rendering function into smaller, reusable helper functions.
Consider moving the HTML-related functions into a separate module/file if the changes become too extensive.
Testing & Documentation
Write test cases to ensure the new functionalities work as expected.
Update the documentation with clear examples on how to:
Is your feature request related to a problem or challenge? Please describe what you are trying to do.
This is a follow on to #1036
There is a suggestion that we should enable a feature to customize the html table rendering.
Describe the solution you'd like
Allow the user to set the amount of data returned. Right now it's hard coded to 2 MB. The actual data size is approximated. We would like this to be customizable.
Allow the user to disable the styling that is applied to the html output.
Optional: Add a way for a user to specify a formatting function to replace the default
ArrayFormatter
. This would enable users to change the data view when they have custom metadataNice to have: Split up some of the html generation into a set of helper functions.
Describe alternatives you've considered
None
Additional context
If this code is getting too large, it may make sense to split it off into a separate file.
The text was updated successfully, but these errors were encountered: