Community Guidelines

Community Ideas

The Tabulator Ideas Repo provides a space for members of the community to share their tips, tricks and code examples with everyone else.

Anyone is welcome to submit a PR with a link to one of the following:

  • Demo / Example - A Code Pen or JS Fiddle demonstrating how to use a table feature
  • Tutorials - Links to tutorials on table features
  • Projects - Links to projects that use Tabulator

The list is intended to be a safe space for developers to help eachother use Tabulator. please make sure you read the Contribution Guidelines before submitting your links.

Getting Help

Having trouble getting Tabulator setup? A feature not working the way you think it should? Then there are plenty of ways you can get help.

Checkout the Quick Start Guide for a demo on getting up and running quickly.
Have a look at the working Examples to see if one of those fits the bill.
Search the Documentation for a guide to the section that is giving you trouble.
Search the Issues Page on GitHub Website
DO NOT ask questions on the Git Hub Issues list, it is reserved for Bug Reports and Feature Requests ONLY!
Be careful when looking at code examples over a year old. Tabulator went through some massive changes when it moved from version 3 to version 4, so old examples may not be helpful.
Search Stack Overflow for an answer in case anyone else has had the same issue. If you are still out of luck, then Ask a question on Stack Overflow using the "tabulator" tag, one of the community will usually get back to you within hours with a helpful response.
When you ask a question, please follow these steps:
Make the title short and descriptive so other users can find the issue easily. Please be polite, do not use all capital letters, this will not get your issue dealt with faster.
Make sure you include a detailed description with the issue you are having, mention which version ot Tabulator you are using, the browser you have been using and include a screenshot or video if it is a visual issue.
Include a copy of your Tabulator constructor object so we have something to test with.

Reporting a Bug

Is Tabulator behaving strangely, have you found a bug? Don't panic, we can fix that in a jiffy!

More often than not the problem is with your code, not Tabulator. To make sure this isn't the case please create a simplified example that contains only Tabulator JS and CSS with no other libraries or style sheets.
If you are still having issues, Search Stack Overflow for an answer in case anyone else has had the same issue. If you are still out of luck, then Ask a question on Stack Overflow using the "tabulator" tag, one of the community will usually get back to you within hours with a helpful response.
Failing that, head over to our Issues Page on GitHub and have a search to see if anyone else has had the same issue. If so vote up the issue with a and include any extra info you have from your bug to help us solve the problem faster.
Please note that all fixes are applied to the master branch and included in the following release. That means that only latest version of Tabulator is supported for bug fixes, i.e. Tabulator is currently on version 4 so we will not be releasing any bug fixes for version 3
If you think you have found an undiscovered bug, please follow the process below to report it:
When you create an bug request issue, please follow these steps:

Create an issue using the Bug Issue Template, make sure the title is short and descriptive so other users can find the issue easily.

Fill in all the fields in the bug template, make sure you include a detailed description of the bug you have found, the browsers you have been able to replicate it in and include a screenshot or video if it is a visual issue.

In order to fix the issue we need to see the problem in action. This means creating a JS Fiddle or Codepen to show a working version of your issue. There are thousands of ways to configure Tabulator and it is impossible for us to offer advice or find the root cause of the issue from a simple description if we cant see how your table is configured.

Be Polite, Tabulator is maintained for free and for the good of the development community, if you cannot be polite and constructive in your comments, your issue will be deleted without discussion!

Make sure you are on the latest release of Tabulator, bug reports will only be accepted against the latest release. (if you are on an old version, your bug may have already been fixed)

You MUST fill in all the fields on the bug template, without them it will be impossible to get to the bottom of your issue as we wont have the information we need to help you.

You should only include small snippets of code in the body of the issue, like a custom formatter function or a small table definition for example. If you are including code in your issue, you must ensure that it is correctly formatted using Markdown to ensure readablility. Large blocks of code if needed should be included in your JS Fiddle.

An example JS Fiddle or CodePen with instructions to replicate the bug is MANDATORY before we will begin work on a fix The example should come with step by step bullet point instructions that should take less than a minute to run through.

DO NOT paste large blocks of code into the issue, it crowds out the issue and makes it completely unreadable. A reduced test case should be created in your JS Fiddle which can then be used to identify the problem.

DO NOT use ALL CAPITAL LETTERS in your title or issue text, it will not get your issue seen to any faster. All issues are treated equally, just because something is urgent to you, does not mean that it is urgent to everyone else.

DO NOT provide example HTML files or zip files containing entire site public folder structures. Tabulator is used by thousands of developers, and we simply don't have the time or resources to be setting up test sites and running through source code for users.

If the table does not work the way you want it to, this is Not a Bug if it behaves as documented. If you believe there are better modes of operation for a certain feature, please create a Feature Request to suggest alternative functionality

DO NOT chase bug fixes by repeatedly asking "when will this be done". Issues are prioritized according to the number of users they affect and the time it will take to investigate and resolve them. Just because an issue is critical to you does not mean that it is critical to most of the user base. Simple bugs will usually be resolved in the next patch release, with more complicated bugs being resolved in the next minor version. If you need something fixing urgently then you can always contribute the fix yourself with a Pull Request

Request A Feature

Have you just had a spark of inspiration? or found that tabulator is missing that critical feature that would make your life much easier? why not let us know and we will see what we can do to help out.

Head over to our Issues Page on GitHub and have a search, see if someone has already requested the same feature, if so vote up the issue with a and add your thoughts to the conversation, to help guide how Tabulator develops.
Check if the feature is already listed on the Development roadmap
If you can't find the feature already, follow the steps below to create a feature request:
When you create an new feature request issue, please follow these steps:

Before creating a feature request, ask yourself if this is something that other users would find useful. Tabulator has thousands of users that all use it in different ways, feature requests should be useful to lots of users. If it is a function specific to your usage case then you should be using the built in extensibility of Tabulator to add that in your own code only.

Is the feature your are asking for within the scope of Tabulator. Tabulator is a library dedicated to interactive management of data in a table structure. If you are going to ask for it to create popup forms or pie charts then these will not be approved as that is not the purpose of this library. As a general rule Tabulator will not make any changes to the DOM outside of the element that the table has been instantiated on.

If you are sure that your suggested feature would be useful to others, then go ahead and create an Feature Request using the Feature Request Issue Template.

Make the title short and descriptive so other users can find the issue easily.
Include as many details about the feature as possible, including a usage case so we can understand why the feature is needed and how it will be used. If you have a proposal for how it shoud work (eg. example setup options or public functions) please include that to.
If the feature will alter the layout of the table please include an image/mockup of how you expect the feature to work.

Be Polite, Tabulator is maintained for free and for the good of the development community, if you cannot be polite and constructive in your comments, your issue will be deleted without discussion!

If you would like to help with adding the feature to Tabulator you can submit a Pull Request with your suggested update.

DO NOT use ALL CAPITAL LETTERS in your title or issue text, it will not get your issue seen to any faster. All issues are treated equaly, just because something is urgent to you, does not mean that it is urgent to everyone else.

DO NOT chase feature requests by repeatedly asking "when will this be done". Issues are prioritized according to how popular they are with the user base, how simple they are to add, when they would fit into the existing Development Roadmap and may other factors. There are many open feature requests and only so much time available so please be patient. Some features may be added in the next release, others you may have to wait more than a year for.

Contributing to Tabulator

As Tabulator has grown, so has our user base. If you are looking for ways to help contribute to the Library then there are many options open to you.

Stack Overflow

Help out less experienced users by answering their questions on Stack Overflow

Issue Tracker Triage

When users create Bug Reports or Feature requests, thier initial submissions can sometimes be missing key details. Help out by providing some initial support to these users:

  • Make sure that issues have been created using the correct template and that all the initial details have been provided
  • Make sure that Bug Reports include a link to a JS Fiddle or Code Pen, and that the example works as thier guide says it should
  • Let users know that questions should be asked on Stack Overflow, not on GitHub
  • Direct users to the original issue if the one they have created is a duplicate
  • Direct users to the Documentation or suggest a workaround if thier issue is not actually a bug or missing feature

Framework Wrappers

There are a number of framework wrappers that have been created to make it easier to integrate Tabulator with JS frameworks, such as React Tabulator and Vue Tabulator

You can either contribute code or documentation to these libraries, or create a new wrapper for a different framework.

We are also always on the look out for basic setup examples where you have integrated Tabulator with a different framework so we can add it to our Framework Support Guide to help out other developers.

Documentation

Tabulator has extensive documentation, let us know if you have spotted any problems by creating a Documentation Issue. Keep an eye out for:

  • Invalid source code examples
  • Broken example tables
  • Typos and spelling mistakes
  • Broken links
  • Missing feature documentation

Pull Requests

If you are feeling adventurous, why not fork Tabulator, make your own modifications and then submit the changes back to us in a Pull Request so others can benefit from your new feature.

If you are looking to make your first pull request on Tabulator, here are some good small places to start:

Please make sure that pull requests only change files in the `/src/` folder and not `/dist/`, the dist folder is auto generated and will be overritten on the next Tabulator update.

Please follow the Custom Build Documentation to generate your own build of Tabulator from your updated source.

Submitting A Pull Request

If you are thinking of adding a feature to Tabulator, then I would like to start of by saying a big THANK YOU. It is always great when a member of the community wants to help out.

Full details on how to use pull requests with GitHub can be found Here.

Before Making a Pull Request

Before you go to the effort of writing code for Tabulator and submitting a pull request, please make sure you follow these steps to make sure that your feature is needed in the table.

Check for existing Feature Requests or Bug Reports related to your contribution to make sure that no one else is working on the same issue.

If no issue exists, create a Feature Request to open discussion on your proposed contribution and get feedback from the community. This is especially important if you are working on a large addition, or change in core functionality as it is likely that any pull request enacting large scale changes will be rejected unlesss there is initial discussion on how it will affect existing Tabulator features.

Think about whether your pull request offers a feature that is useful to all of Tabulators users or is just to address a specific use case for your project. To avoid cluttering the code base, pull requests will not be considered for features that only address edge cases.

Does your usage case alter the default functionality of the table? Pull requests to add functionality must not change the current default user experience of the table (unless you are fixing a bug), if you are adding a new option to the table then the current mode of operation must remain the default.

Does your change work well with the other modules in the table? updates to Tabulator must be considered in the context of the table as a whole, an update must work as expected in any configuration of the table and should not break any existing functionality

Please make sure you fully understand the existing codebase before submitting a Pull Request. One of the most frequest issues we face with new pull requests is users fixing an issue for themselves but breaking other table functionality

DO NOT submit a PR that makes significant changes to library functionality or that goes against the roadmap without starting a Feature Request to talk about it first as it will likely be rejected

DO start small. Take time to get to know Tabulator before tackling big changes. Start out with bug fixes and small features first and work up to larger scale updates.

Writing Your Code

Please follow these guidelines when writing code for Tabulator:

In order to keep the codebase consistent and clean, please follow the existing coding style of Tabulator. Pull requests with extensive changes to the existing code style will NOT be accepted. for example:

  • no additional spaces are required around functions and parentheses
  • prefix function names with underscores if they are internal to modules and should be considered private
  • if statements must use curly braces unless they are ternary
  • functions on modules must be added to the prototype to improve efficiency

If you are writing code to extend an existing module, keep all code contained within that module. The point of abstracting code into these modules is to make it easier to maintain.

When calling functions on a module from outside the module, you should always call the modExists function on the table first to check that the module as been included. This is because modules are optional and may not always be available

Any functions that return row, column or cell objects, should call the GetComponent on them to get the Component Object and return this instead. This provides a safe public wrapper around internal table functionality

TEST YOUR CODE before submitting your Pull Reqest. One of the most frequent issues we face with new pull requests is users fixing an issue for themselves but breaking other table functionality

Make sure your update works on all Supported Browsers

Changes should ONLY be made to files in the /src folder. The /dist folder is automatically generated and any changes there will be automatically overwritten

Do not leave excessive comments in the code. Your functions and variables should be named in a way that makes their purpose obvious. Do not leave comments about why you have made changes, these should be included in your pull request details. Do not use the comments to leave your initials in the code. Your commit will be a record of your contribution, the codebase should not be polluted with personal tags.

Do not call public API functions on the table (listed in the /src/core.js file) when you are writing code internal to the table. the core.js file acts as a wrapper to encapsulate and bridge the external API to internal table functions.

Do not use query selectors in your code. Any elements added to the DOM should have the reference to the node stored in a variable, and that variable used to access the node at a later date. Tabulator has to handle 1000's of DOM elements very quickly and query selectors slow everything down. PR's using query selectors will automatically be rejected!

Do not make changes to files in the /dist folder, this folder is automatically generated and any changes there will be automatically overwritten next time the source is updated. Any PR's with changes to these files will automatically be rejected!

Submitting A Pull Request

When you are ready to submit your pull request, please consider the following:

Make the title short and descriptive so other users can find the it easily.

Tag the Feature Request or Bug Report related to the PR to add context to the submission and help other users join in the discussion.

Include as many details about the additions as possible, including a usage case and example code snippet so we can understand why the PR is needed and how it will be used by other users.

Make sure that you are submitting your code against the correct branch. Most PR's should be made against the master branch unless your are contributing a feature from the roadmap to a specific version.

Submitting a Pull Request is a collaborative process. Once you have submitted your pull request you should expect a dialog with the reviewer who will guide you through any changes that need to be made before the PR can be accepted and merged into the code base. If the overall concept of your PR has been approved it will be given the state of PR Needs Work until all outstanding points of the reviewer have been addressed.

Do not expect your code to be merged into the codebase straight away. In order to make sure that users are kept up to date with changes, PR's are only merged into the master branch when a new version of Tabulator is released and the documentation is updated. If your PR has been approved and is waiting for the next release it will be given the state of PR Awaiting Merge. Bug fixes are usually merged into patch releases which happen every week or two, feature updates will be included in minor releases which happen every 2 to 3 months.

Development Roadmap

If you want to have a look at what is ahead for Tabulator in the coming year, head over to Trello and checkout our Development Roadmap.

The roadmap is a working document that is subject to continuous change as the needs of Tabulator's users change, it should give you an idea of Tabulators direction.

If you feel there is anything missing from the roadmap, check out the New Features section of this page to find out how to make feature requests.

Want to Say Thanks

Enjoying Tabulator? Wanna say thanks to the chap who built it? Aren’t you a lovely person

Git Hub Community

If you want to show your support for Tabulator, please head over to our GitHub Page and click that Star button in top right hand corner to show other users what you think.
Better yet, why not introduce your developer friends to Tabulator, see if you can make their table building tasks that little bit easier too!

Donation

If you are one of those exceptionally generous people that wants to make a financial donation then please head over to the support page to find out how to.