When creating modern WebParts in SPFx, sometimes it becomes necessary, or at least recommended, to share data between WebParts. For example, if one WebPart is querying the same data source as another, it simply makes more sense to perform the query once. Then, you can share the results between the two WebParts. Additionally, we may want to share locally manipulated data between WebParts, similar to the PnP Modern Search WebParts. Originally, SPFx didn’t allow this out of the box, which led many of us to other React solutions, such as Mobx. However, SPFx 1.7 introduced Dynamic Data Sources, allowing WebParts to be connected and share data. Which begs the question: when should one use Dynamic Data Sources instead of Mobx?
Of course, there’s no easy answer
If there was an easy answer for this one, it wouldn’t really make for an interesting blog post, would it? There are several factors we need to consider here, including how the data is being retrieved, how the data is represented if it’s being modified, what subsequent data depends on our connected data, and what packages we’re already utilizing. All of these considerations and more help determine whether Dynamic Data’s source notification model or Mobx’s transparent reactivity is best suited for the job. Dynamic Data utilizes a push-pull system to share data via a “change notification” system. Mobx, on the other hand, relies on declaring observability on individual properties and automatically re-rendering components through its subscriptions.
How is the data retrieved?
First, we should consider if sharing data between WebParts is actually necessary. One should first ask themselves what data is necessary for each WebPart. Perhaps we need to query separate lists for multiple WebParts. If we need to make separate queries anyway, we won’t see much benefit by combining all of the calls into a single WebPart.
However, if we’re facing a situation where we can combine our queries into a single call and filter the data client-side for each WebPart, it probably makes more sense to perform a single large, unfiltered call instead of multiple filtered calls.
Who is authoring the pages?
One advantage of the SPFx Dynamic Data Source is that it’s easy for a power user to configure dynamic data sources through the UI, as shown in the below screenshot.
Mobx, on the other hand, is configured behind the scenes. If a power user doesn’t have access to the code, they won’t be able to see how data is shared or modify it.
How is the data represented?
Although SPFx’s Dynamic Data Source solution works well and is easy for an end-user to configure, it also comes with some caveats. In my testing, I found that strings can be easily shared, however more complex data structures and arrays aren’t necessarily as reliable. My workaround for this was a simple JSON Stringify and Parse so that it’s sent between WebParts as a string. While this works, it isn’t exactly the most convenient option, and can also be error-prone on the receiving end of a JSON string is empty or invalid.
On the flip side, Mobx is able to share complex data structures and arrays with ease. There’s no need to stringify the data when accessing it in separate WebParts.
Is the data flowing just one way?
If your data is simply being retrieved and rendered by a WebPart with no modifications, Dynamic Data Sources can be sufficient. However, if data is flowing both ways on the wire – that is, to say, data can be modified and posted back to the data source – Mobx is a cleaner solution.
With Mobx, we can create observers and trigger certain operations when data is changed and needs to be sent to the backend.
Are subsequent calculations necessary?
Sometimes, we find ourselves performing calculations on data using a formula or a string replace. If this is the case, rather than manually determining when the calculations need to be updated, we can leverage Mobx’s @computed property attribute. @computed will refresh a “calculation” whenever the answer will change, such as when data is refreshed or modified. However, this can be a double-edged sword. In using Mobx’s computed properties, it’s possible to accidentally create circular computed logic or negatively impact performance by oversubscribing.
Code overhead considerations
Although it’s clear that Mobx is a more robust solution than a SPFx Dynamic Data Source, it also comes with a significant amount of overhead. Since we need to install and import Mobx, our package size is impacted. Additionally, Mobx takes a fair amount of configuration, especially if you aren’t already using a WebPart – Store – Service model.
On the other hand, the wirings for Dynamic Data Sources are installed alongside SPFx 1.7 or above, so an additional install is not required. If you prefer to call your Service layer directly from your WebPart without a Store, it’s easier to configure a Dynamic Data Source than Mobx.
In Summary
SPFx Dynamic Data and Mobx server similar, but distinctly different purposes. If you’re working with complicated data sets that you need to interact with often and aren’t worried about adding extra overhead, Mobx is probably the right choice for you. Alternatively, if you’re just trying to share a single query with other static web parts, SPFx Dynamic Data is probably the better choice, so you can up and running quickly.
Want to reference this information quickly in the future? Check out the diagram below.
Lastly, shout out to my co-worker Annie Johnson for her feedback and contributions on this blog post – thanks, Annie!