Forum Discussion

Tim's avatar
Tim
Data Pipeline
07-17-2024
Solved

Javascript custom properties

I wrote javascript that creates a dashboard filter. I want my javascript to mark which filter it created. That way, on the next refresh, it can update or delete it if needed.

I've done that by creating a new property like this: dashboard.filters(choose the one I want).jaql.MyNewProperty = "true".

My question is: It's working for me now, but is this solution robust long-term? Any caveats I should be aware of? Are custom properties on widgets/filters/etc. a good tool for future projects? 

Developers
  • rapidbisupport's avatar
    rapidbisupport
    07-18-2024

    Hi Tim ,

    We (at RAPID BI) initially struggled to make custom properties 'stick' to items. These were metadata items as well as filter items. I remember this issue when I was extending our internal RAPID BI Hide Filters plugin, that allowed our designers to set and then hide filters on the filter shelf. I'm not sure if this is still the case in 2024.2.

    As a rule of thumb, we try to add custom properties to the style or options properties within a widget or dashboard. In the case of the hideFilters, a work around I found for this was to create an array under dashboard.style.hiddenFilters = [filterid1, filterid2, ...] for those hidden that I wanted to reference afterwards.

    This coupled with the dashboard.updateDashboard(dashboard, "filters"); or widget.changesMade() ensured the property was saved on either a widget or dashboard level (i think in the background, this does some PUT request against the widget/dashboard and updates the definition in mongo prismDB).

    Additionally, I don't think you'd want to store any 'large' data here, but I have seen instances where plugins have hijacked the 'format' object on metadata items (widget.metadata.panels[i].items[j].format) and added lots and lots of per-value formatting definitions (I think this was the community custom bar chart addon that no longer seems to work).

    This said, i'd love to hear how others have tackled this situation. It'd be good to hear Sisense input ( DRay ?) on this also, although I suspect they'd probably bring up the https://sisense.dev/guides/restApi/custom-data.html as a more official way of storing data like this (which we also use, but in other plugins and scenarios).

    Would be happy to talk through some of the things we considered on this if you'd like - feel free to take us up on our free 30-minute consult: https://www.rapidbi.com.au/sisense-add-ons/Services/Free-30-Minute-Sisense-Consultation/

    Let me know how you go?

    Thanks,

    Daniel

    RAPID BI

    [email protected]

    RAPID BI - Sisense Professional Services | Implementations | Custom Add-ons

     

3 Replies

  • rapidbisupport's avatar
    rapidbisupport
    Data Pipeline
    07-18-2024

    Hi Tim ,

    We (at RAPID BI) initially struggled to make custom properties 'stick' to items. These were metadata items as well as filter items. I remember this issue when I was extending our internal RAPID BI Hide Filters plugin, that allowed our designers to set and then hide filters on the filter shelf. I'm not sure if this is still the case in 2024.2.

    As a rule of thumb, we try to add custom properties to the style or options properties within a widget or dashboard. In the case of the hideFilters, a work around I found for this was to create an array under dashboard.style.hiddenFilters = [filterid1, filterid2, ...] for those hidden that I wanted to reference afterwards.

    This coupled with the dashboard.updateDashboard(dashboard, "filters"); or widget.changesMade() ensured the property was saved on either a widget or dashboard level (i think in the background, this does some PUT request against the widget/dashboard and updates the definition in mongo prismDB).

    Additionally, I don't think you'd want to store any 'large' data here, but I have seen instances where plugins have hijacked the 'format' object on metadata items (widget.metadata.panels[i].items[j].format) and added lots and lots of per-value formatting definitions (I think this was the community custom bar chart addon that no longer seems to work).

    This said, i'd love to hear how others have tackled this situation. It'd be good to hear Sisense input ( DRay ?) on this also, although I suspect they'd probably bring up the https://sisense.dev/guides/restApi/custom-data.html as a more official way of storing data like this (which we also use, but in other plugins and scenarios).

    Would be happy to talk through some of the things we considered on this if you'd like - feel free to take us up on our free 30-minute consult: https://www.rapidbi.com.au/sisense-add-ons/Services/Free-30-Minute-Sisense-Consultation/

    Let me know how you go?

    Thanks,

    Daniel

    RAPID BI

    [email protected]

    RAPID BI - Sisense Professional Services | Implementations | Custom Add-ons

     

  • Tim's avatar
    Tim
    Data Pipeline
    08-06-2024

    Hi Daniel(s),

    Thanks for your reply - it's reassuring seeing someone else working with custom properties like this.

    "... add custom properties to the style or options properties ... dashboard.updateDashboard ..." - Thanks for the tip. I guess otherwise there's a chance the custom property gets lost depending on what combination of refresh/user-logout/server-reboot/etc. happens. My Version1 is storing the property within the filter object, which seems stable so far, but I'll shift it to dashboard.options if we find any issues.

    "consult" - I'll keep you in mind. Good to know you're available as a resource.

  • DRay's avatar
    DRay
    Admin
    08-01-2024

    Hello Tim ,

    I wanted to follow up to see if the solution offered by rapidbisupport worked for you.

    If so, please click the 'Accept as Solution' button on the appropriate post, that way other users with the same questions can find the answer. If not, please let us know so that we can continue to help.

    Thank you.