Custom Dataset

A custom dataset is a dataset that is not connected to a collection but has a custom/editable schema.

Dataset's schema would be configured via the editor (not code) where you can define a list of <key:type>. Where key is the name of property/field and type is one Wix supported types (string, number, date, URL, image, ...). Once the dataset is set up in the editor's UI, coder can inject data into it with a command like

$w("#customDataset").data = [{_id:"0014-54015-486", title:"my item title, price:475, orderDate: dateObj}, ...];

For the rest, it would work like any other dataset. It can, therefore, be bound to a UI element or a repeater.

Why would we need such a feature?

In my opinion, this solves many problems thanks to the separation of concern! Having to select an element by its id, strongly tied our code to the UI. Wix Editor is one of the most flexible page builders but as soon as you want to use custom code, it crystallizes everything. Change one id, move one element from a container and the whole app stop working.

Being able to separate concerns has the following benefit:

Better collaboration with Developer: Developers don't have to wait for designers to finish the whole UI in order to work on the app view. He simply injects data in the custom dataset and the designer does the binding as he sees fit.

Better collaboration with Designer: Designer only need to define the data he would like to work with (dataset's schema). The developer only focuses on bringing that data without concern for the UI.

Resilience to design changes: Once an app is done, a designer (or any collaborator) can update the UI without breaking the code.

Resilience to code changes: If code needs to update it's simpler to update 1 dataset rather then several elements.

Resilience to data changes: if a collection structure changed, having a proxy dataset will mitigate the effect.

Code portability: Copy your code to another page/website, create a new custom dataset and bind it to the new page without renaming all your ids.

True parallels working: Since code will not rely on ids, developers can work together on locally on js files (using git) and push their changes without knowledge about the UI and without altering anything the UI.

You might say that we can achieve something similar with classical dataset but:

We don't always have a collection to hold our data: information might come from an external API or a config file.

Final database structure might not be available when the work started or might change with time.

Data often need to be processed before being display, using a classic dataset with raw data is not an option there.