[GitHub] [superset] geido commented on pull request #18009: feat: log scale and step size control for range filters [WIP]

[GitBox <gi...@apache.org>]

geido commented on pull request #18009:
URL: https://github.com/apache/superset/pull/18009#issuecomment-1085898918


   > > We might want to rearrange the controls. Clicking on "Filter has default value" triggers displaying default value control above the step controls, while step controls affect how default value picker works - that probably means that step controls should be above default value. <img alt="image" width="631" src="https://user-images.githubusercontent.com/15073128/161026010-8ac3b3d5-f271-44bb-9581-4bfc5233655e.png">
   > > CC @kasiazjc
   > 
   > That's an interesting observation but I have no idea how to do that. The default value stuff code is handled somewhere else, and honestly I'm not sure how it decides on the location of controlPanel components. In the controlPanel code for the Range Filter, I have
   > 
   > ```
   >     {
   >       label: t('UI Configuration'),
   >       expanded: true,
   >       controlSetRows: [
   >         [
   >           {
   >             name: 'enableEmptyFilter',
   >             config: {
   >               type: 'CheckboxControl',
   >               label: t('Filter value is required'),
   >               default: false,
   >               renderTrigger: true,
   >               description: t(
   >                 'User must select a value before applying the filter',
   >               ),
   >             },
   >           },
   >           {
   >             name: 'enableSingleValue',
   >             config: {
   >               type: 'CheckboxControl',
   >               label: t('Single value'),
   >               default: SingleValueType.Exact,
   >               renderTrigger: true,
   >               description: t('Use only a single value.'),
   >             },
   >           },
   >         ],
   >         [
   >           {
   >             name: 'scaling',
   >             config: {
   >               type: 'SelectControl',
   >               label: t('Scaling Function'),
   >               default: PluginFilterRangeScalingFunctions.LINEAR,
   >               renderTrigger: true,
   >               freeForm: false,
   >               choices: Object.keys(
   >                 SCALING_FUNCTION_ENUM_TO_SCALING_FUNCTION,
   >               ).map(key => [
   >                 key,
   >                 SCALING_FUNCTION_ENUM_TO_SCALING_FUNCTION[key].display,
   >               ]),
   >               description: t('Choose a scaling function for the slider.'),
   >             },
   >           },
   >           {
   >             name: 'stepSize',
   >             config: {
   >               type: 'SelectControl',
   >               label: t('Step Size'),
   >               default: 1,
   >               renderTrigger: true,
   >               freeForm: true,
   >               choices: [
   >                 [0.001, 0.001],
   >                 [0.01, 0.01],
   >                 [0.1, 0.1],
   >                 [1, 1],
   >                 [2, 2],
   >                 [10, 10],
   >                 [25, 25],
   >                 [100, 100],
   >               ],
   >               description: t('Set the slider step size.'),
   >             },
   >           },
   >         ],
   >       ],
   >     },
   > ```
   > 
   > But you can clearly see that's not the order the modal decides to put stuff. enableEmptyFilter is the last control in the modal, yet the first in the controlSetRows array. I still don't get exactly how that controlSetRows should be structured, as I would have thought the enableEmptyFilter and enableSingleValue controls would be on the same row (since they're in the same controlSetRow) which is (I believe) how it works for visualization controlPanel configs.
   
   @stevetracvc @kgabryje 
   
   We had a conversation with @michael-s-molina who has suggested the following:
   
   - The easiest solution is just to leave it in the current position if we can live with it (of course)
   - Another way is to move the code directly into `FiltersConfigForm` between the description and the default value
   
   You are right this wasn't straightforward forward but we aim to improve the codebase of native filters in the upcoming phase 2.
   
   Some other observations that came out from our conversation:
   
   - This functionality should be under a checkbox as it’s very specific, such as “Customise default step scaling function”
   - The inputs should not take the full width of the Modal. Please follow the same UI of existing inputs
   - If the step size is lower than two decimals, the exact number of decimals should also be visible in the left sidebar, otherwise it’s impossible to see those decimals changing.
   
   Let me know if you have any questions. Thanks for the hard work!
   
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org