How should we deal with project-specific stuff in Data Explorer?

[EvgeniiaVak]

My assumption was that we want to make Data Explorer as reusable as possible (that's why there are no CSS for example - they will be defined in the themes), but also I thought that Data Explorer should be very centralized, meaning no project-specific branches and extending the common code when possible. But I see there is the EDS branch, so I might have been wrong.

My suggestion would be to never create project-specific branches if possible and add features that might be needed by other projects in the future to the common code.

@starsinmypockets @anuveyatsu what do you think about it?

[starsinmypockets]

@EvgeniiaVak this sounds like the right idea to me also: centralize code and make it reusable.

I do also wish that there was some pluggable mechanism for overriding templates, extending behavior, etc similar to the how themes/plugins work in a CMS / DMS). For instance if someone wanted to:

• change the layout of the data explorer in an arbitrary way:
  • move chart-builder to left column instead of right
  • move query tool to bottom
• Implement an addition tab, or show multiple tabs at the same time (chart + map)

I'm guessing that this is out of the scope of this project, but it something that I would like to continue to think about.

[anuveyatsu]

@EvgeniiaVak I totally agree with you, however, there is some bespoke client requirements that should not be in master branch.

[anuveyatsu]

@EvgeniiaVak I have a nice example right now:

• Client X wants field title to be used as a column header so that they can have human readable headers (e.g., they have been doing it for 1-2 years alread).
• Client Y doesn't like it - they think data table should not use title/label in the headers. They believe it should be displayed as is using field name.

There is way to fix it, e.g., we can have field.displayHeader which points to key, e.g., field.title for client X and field.name for client Y.

Problem is that over time we can end up with a lot of configurations..

[EvgeniiaVak]

@anuveyatsu

Ok, but still interesting how we decide what is worth extracting to config and what is not. Maybe by counting feature requests by clients? Once a feature is requested more than once add it to master. But then we need to have some list of these features or something like that. If we don't do anything we might end up reinventing the wheel over and over.