In an SPA, your page should not have a content type set.
No, that is kind of what the post is trying to help people understand, that just because you have a datasource for a group, not every child group needs to have the same data source, so bringing this to the sense of page content type or reusable content type, any groups you place on the page or the reusable can have their own content type that is different.
Yes, in the post I state that it is best to reference either the page content type, the reusable content type but I also mention that at times I have groups that are used as the reference for the data source. The main concept is that to continuously just pass the value down from one container to the next using the ‘parent groups’ thing is not best practice as there are other sources, mostly from the context of having multiple child groups that do not need the data since they do not have an immediate child element that is displaying the data. So think about a situation in which there are 4 groups that are necessary for getting the right design layout, and it is in the 4th group that a child element of a text element needs to display a value…group 1, 2, 3 and 4 do not need to have a data type set and do not need to have the value passed down by referencing parent groups thing because in that text element you can very easily use the ‘current page thing’ or ‘reusable thing’ or ‘reusable property’ or ‘reference groups thing’, making such that when you want to copy and repurpose those elements in the same app or another app, you will not need to alter group 1, 2, 3, and 4 content type and would most likely (if the naming culture expressed as an additional tipe in the post is also followed) only need to change either page content type, reusable, or reference groups content type.
You do not necessarily need to use a URL parameter, and those too should not be overused. Depending on the app setup and UX as well as features, a URL parameter may not be necessary at all, and should not be considered as a blanket fix/reference of data for all situations. I use a URL parameter as a datasource in the past for reusables to more easily communicate with the page, and this is not necessary now due to properties, but I do have features I implement into apps, like showing a single selected value in a repeating group and I use a URL parameter for that single selected value to be in the URL for the purposes of having a URL that can be shared or emailed so that somebody can follow that link and see the exact entry of importance. I use URL parameters for navigation, especially for a dashboard or SPA to change views (but if my SPA needs SEO, I use URL paths instead). Most of the time for a dashboard or SPA, my group has a content type set to a option set, with a condition to be visible only when the URL parameter value is the parent groups option, and that option set is used for the navigation menu. Inside of that container group with a content type of the option set value is most likely a reusable element that has all the elements/features/functions necessary for that ‘view’.
Don’t overuse reusable elements either. Recently I started to rebuild an app previously started by other developers who overused the reusable elements. They had buttons as a reusable element when it should have been just a button on the actual reusable element that required the button. Basically they had about 10 reusable elements that I had to pick apart and turn into the one reusable element necessary. A lot of times people pick up a new trick or have a unique approach to something and they begin to overuse it and apply it to situations where it is unnecessary and makes maintaining/debugging an app more complicated and tedious than necessary.