Newbie Questions on dataViewMappings and ColorHelper

Hi jonnyglass,

One of the hardest challenges coming from a D3 background is that it's relatively easy to port your knowledge to Power BI visuals, but the concept of dynamically changing datasets (either through cardinality or sheer number of possible use cases when it comes to an end-user's model, plus handling dynamic sizing etc.) is where you can start to rack up the hours 😉

With data mappings, yes, you choose the most suitable one. table is easiest to start with, as it's similar to how many d3 examples etc. work, so is very flexible, particularly as visuals only have a single query, and therefore dataset. You can do whatever transforms you like in your code to achieve what you want, but when it comes to binding data back to Power BI - for example by distinct values in a particular column for colour assignment or interactivity purposes - it is the least flexible. It is not easy to reconcile by a high-level grouping over several rows and this is what the categorical or matrix mappings are for: you specify how the data gets grouped in the data view mapping and you can pass the details of that group's "selector" back to Power BI for reconciliation.

It is a hard concept to explain succinctly, but in short, the visual dataset is pushed from the main window and you cannot directly talk back to the model except for exposed APIs. In these cases, you use selectors to signal to Power BI how to delegate what you want to do , based on what it knows about the dataset it gave you orginally and what it knows about the data in other visuals on the page.

If you want to so colour assignment and you are expecting to do this by distinct values, this is where you might use a categorical mapping, in conjunction with the categorical and series properties. By specifying that Power BI group them this way, you can create selectors for these groups, which will ensure that Power BI knows to treat them en masse when assigning colours and displaying the entries in the properties pane, ot managing cross-filtering or drillthrough based on a unique value. Similarly this limits what you may be able to do with your data inside your visual, so there is a possible compromise in flexibility this way. It's a bit of a balancing act.

If you want a 'real-world' visual to look at, then I have developed this one as part of a course which intends to provide end-to-end coverage of development - the visual itself is open source and heavily commented for newcomers, so if you don't want to pay for the lessons then it may give you enough context to work your existing knowlege into what needs to be done to make things play nicely with Power BI.

Regarding your low cardinality, Power BI will group data by distinct values, so if you are seeing a low number of rows it is likely that your start/end dates are being treated as implicit measures. You might want to see if Power BI is aggregating by checking the field. For example, if Don't summarize is not checked, then it should work as you expect:

The other thing to consider is if you're adding a measure to a grouping column, Power BI will always aggregate to the highest level, so you will need to add a suitable column to create the necessary row context. This may not be your issue but it is something to thing about. I have an article that explains the concepts a bit further here which may help solidify your understanding. It's from an end-user pespective but does list a few common gotchas for those of use used to having a single row for what we assume is a dataset we're familiar with.

Hopefully some of this may help. Good luck!

Daniel