robertseidler / wc-grid-table Goto Github PK

Data regularly needs to be exported to excel/csv. Especially filtered/reordered data would be nice to export.

• maybe an option what data is exported (original/filtered/paged). Default should be filtered
• maybe add maps for data to be easier handled in excel (numbers without formats)
• add targets for export (excel/csv/json/etc.)
• add dependencies to generate (especially) excel target

possible libraries: xlsx

Most of the documentation is only in written down in comments of the original script. A lot of those comments are outdated.
Also change them to jsdoc notation, if they aren't already.

When the data of a table is to large, the table script is overloaded with work. Server side pagination could solve this problem.

• maybe wait until #25 is done, so that we can use T-SQLs pagination to load individual pages.
• filter and sort features have to change the T-SQL filter (where) and sort (order by) options (a query builder like knex.js could easily solve this problem).
• maybe cache some pages for faster loading of previous pages
• maybe reset page number, when filter or order is changed

Using jsdoc notation to add types to all js-files.

• First goal is adding types to all exposed functions
• Second goal is adding to all other functions like privates and closure functions.

Goal is to render wiki-pages independent of table data and thereby cutting page loading times of prot-wiki (right now all data has to be loaded before rendering can start).

Right now, data is fetched by reading from a json file, which is (generally) provided by the backend.
By connecting to the database ourselfs or by adding a service, that provides this data (including an appropriate level of security), we can change the way pages in wiki are loaded.

Also often tables are used in (non-visible on initial render) tabs in wiki. Maybe we could add an option to lazy load them, only when they are visible.

• maybe change test dependency to (Mochajs) npm install --save-dev mocha from jest
  Priority Order for new test cases:
• 1. non intuitive code like regex and long map-chains
• 2. functions changing the data
• 3. all functions in filter-utils.js and pagination-utils.js

Right now column chooser (changes which columns are visible) is rendered under the table. I would prefer this menu being in a popup (probably full page popup).

Plugin system to support things like marker-input.

• possible other extractable functionality includes filter (maybe even filter operators), pagination provider, etc.
• maybe plugins can be categorised by their entry point (data-plugins hook into the setData method; init-plugins hook into connectedCallback, ui-plugins hook into the button-container-creation method).