PROBLEM After upgrading their Skuid package, a client noticed that an existing page’s bubble chart was not showing bubbles with different sizes, as it should.
- We determined that there was a product issue at work here, and we drafted a possible workaround for certain use cases.
Consider upgrading to 12.4.17+, which addresses the root product issue.
- If you must stay on a Skuid version between 12.2.8 - 12.4.16, consider turning on aggregations for the problematic chart size field, assuming it does not affect the data's presentation.
A bubble chart has 3 axes available to show numerical data. The X and Y axes work as you’d expect: up/down and left/right. The Z axis determines the size of each bubble, and each bubble sits on one of the points in the XY axis. A client’s bubble chart was previously working in Skuid Spark Update 1, but after upgrading a sandbox to Spark Update 3, the bubble’s sizes (i.e. Z axis values) were all the same, despite the data being different.
Since the issue was visible in a sandbox, we first looked at the chart’s data to determine if the sandbox’s data was incomplete, or if perhaps all the values in the Z axis’s field were identical or empty. We saw that the field’s values were not empty, and were indeed different, by adding a table to the page that showed the records and relevant fields. We also verified that the table data was correct by using skuid.model.map() in V1 (or skuid.debug.modelMap() in V2) in the browser’s console to look into the chart model’s data array.
We looked into whether the chart might be rendering before all the model’s data was available (i.e. too soon). This wouldn’t normally happen in a model query, but if there was a reason some of the chart’s data wasn’t immediately available, this problem could arise.
One way to do this is to re-render the chart by adding a button that will hide the chart and show it again using the Toggle Component action
We created a page with just one UI-only model and 3 fields called Xaxis, Yaxis and Zaxis.
To add data rows to our model, we used an event-triggered action sequence triggered on the Skuid: page rendered event. This ran the Create New Row action a few times, giving each row different values for the X Y and Z axis fields.
Given our findings up to this point, we suspected that a product change may have come along between the previous (12.1.6) and present (12.4.15 at the time) versions of Skuid. To try and verify this, we looked through the release notes on Skuid’s releases page for any changes that mention “Bubble Charts” or “Charts.”
With the simplest possible setup, which didn’t use any real data from the environment or the client’s existing page, we still saw the bubble size issue in the upgraded sandbox. So, we took our simple test page and tried it in other environments. Specifically, we tried it in a sandbox that was still using the client’s previous version of Skuid. In that sandbox, we saw that the test page worked as expected, and did not exhibit the bubble size issue.
We found that in Skuid release 12.2.8, a fix was made to address a similar-sounding issue to bubble charts.
It looked like there had previously been an issue with the “Size Aggregate” function on bubble chart’s size field. Since our client’s charts were not using any size aggregations like this, we believed that the change made to fix the issue for aggregations caused issues for charts that do not use aggregations.
We found that turning on aggregations for this chart’s size field allowed the bubble sizes to show. This could be a workaround if the aggregation doesn’t affect the data’s presentation (as was true in the client’s case). We surfaced this to our Skuid engineers, who found a root cause. A product fix was recently released in Skuid release 12.4.17 to correct both aggregated and non-aggregated bubble chart size issues (see DSC-2541 in our release notes).
We were thankful to have caught this issue in a sandbox rather than in production. Our clients followed best practices by testing their solutions after upgrading a sandbox, and thus were able to avoid introducing the issue to end-users.
Confirming that there’s a product issue at work is difficult. Our clients build complex solutions that serve complex needs, and understanding all of the factors that influence a page’s misbehavior means finding useful ways to focus on what matters to the issue. That’s why we didn’t make much progress in this investigation until we tried to build a reproduction/test page from scratch as simply as possible. With that in hand, we next needed to leverage the resources available (our releases page, a second non-upgraded sandbox, etc.) to find out why upgrading the Skuid package caused this change in behavior.
It’s not always the case that a problem like this is the result of a product issue. The problem could have been that the sandbox’s data didn’t have any values in the field used for the Z axis. A permissions issue also could have hidden the field from the test user in this environment. To confirm that the product itself is behind a problem, we work first to rule out all other variables.
Get help with an issue
Ask in the Skuid user community in the
If you have paid support, ask your question on our support portal
- If you’re interested in support, contact your Account Executive.