-
Notifications
You must be signed in to change notification settings - Fork 4.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove "context" prop from visualizations #4789
Merged
Merged
Changes from all commits
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@gabrieldutra That's definitely a right direction, but let's improve it even more. Let's not extent visualization's options, but instead pass a new prop (
customOptions
,rendererOptions
, whatever) of typeobject
. It will contain additional settings likepaginationSize
.VisualizationRenderer
should also take this prop and just pass it to the Renderer.And usage in widget component:
<VisualizationRenderer ...(existing props) customOptions={{ paginationSize: "small" }}>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kravets-levko I thought about that too, but somehow that's still a layout option for the Table visualization, although we don't offer it as a setting. So why not keep it it simple and leave it in the unified place for options instead of creating a new prop?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have some concerns about this solution.
First of all, visualization options object should contain only options that could be edited by user (not necessarily right now, we might have some "hidden" options that aren't available in UI, but they behave like other ones). That's not good if we introduce some "magic" option that comes from somewhere else than corresponding "getOptions" function. Furthermore, it's 2x bad when that option (which in fact depends on state of app that uses library) comes from a wrapper component where it's hard-coded and depends on visualization type. Therefore I suggested a new prop.
Regarding
Pagination size depends on where visualization is used in the app, so in fact we still keep that "context" concept, but call it in a different way (we directly map context to paginationSize).
That's what my idea solves: if app needs to change pagination size, then app should tell about it. No any magic and hardcode in the library. Also, some of other visualizations have pagination as well (e.g. Details), so that custom option may be used there (BTW - good chance to implement it now 🙂). And the app is the only right place to decide when we need small pagination - library should just do what the app says.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll give some more time to think about that, but first I'll give you more details on why I went that way.
When thinking in isolated Renderer and Editor, there's not much of an "could be edited by user" concept. I was thinking of the Renderer by being a "you give the Type, the Data and the Options and it renders your component" (so in here the "options" seemed to just be the right place for it). Also there shouldn't be a problem on having this option on
getOptions
(and it probably should be there, it's just that I forgot to add it).The way I was trying to think about it was: In an isolated, non-Redash app, what would be the way to provide the
paginationSize
as a setting. The "static" part of it is a Redash thing, thus there's the "hack" of making it a static option over the renderer options.I see your point though, I'll give it some time to think, if it's really necessary I'll introduce a
renderOptions
orstaticOptions
in there too. I just don't want to give complexity on the Library use as I see it can be confusing since there's no clear difference between that new option and the "options" itself when you forget about the Redash use for it.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you, now I see your point. I think we could end up with something between: for me it looks more or less fine to pass
paginationSize
among visualization options, BUT:getOptions
;WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Currently
EditVisualizationDialog
andVisualizationRenderer
are the ones on the Redash side that are abstracting visualizations for Redash use. I hope those become clearer once the separating process is done (and so we can rethink about how to structure such abstractions).