You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For state management, every ATable component uses an instance of a data store class (TableDataStore) that has the following features:
Each table instance (in case of multiple table renders) auto-generates an ID for itself to allow identifying individual tables.
If a table uses modal components, then the instance ID is also automatically shared to the modal component(s).
Each table instance is individually provided to the current Vue instance on setup.
Each table instance also exposes a setCellData API to update the table's data.
Problem:
When a table cell can be edited via both the cell and modal inputs, syncing the cell -> modal action isn't currently straightforward via the API, which breaks two-way reactivity in the table.
Explanation:
The above happens because implementing an ATable component in a file doesn't give you easy access to the data store (the unique class instance ID isn't exposed), which means trying to use the setCellData API in that file is a hassle.
Possible solutions:
I think there's multiple iterations that can happen to fix this issue, some of which include:
At the very minimum, ATable can expose the data store class after initialization. Vue has a defineExpose API that can let parent components access attributes inside the ATable component (tableData, for our purpose here).
We can also use a state-management plugin like Pinia to implement shared states (+ APIs) without relying on provide/inject/expose.
In cases of multiple tables, this could either mean defining a store instance per ATable (differentiated using the id?), or maintaining a shared store which can hold all table states simultaneously. Either case would also work in parallel with other stores defined in the future inside the Stonecrop context.
Example using exposed attributes (doesn't work perfectly, but this should be useful for the concept atleast 😅):
// Implementation.vue
<template>
<ATableref="table" />
</template>
<script setup>
consttableRows=ref([])consttableRef=useTemplateRef('table')watch(tableRef, (table) => {// access the data in the table defined in the templatetableRows.value= table?.tableData.rows})watch(tableRows, (rows) => {constcellData= {} // figure out which cell has changedtableRef.value?.tableData.setCellData() // use store APIs to update cell data})</script>
The text was updated successfully, but these errors were encountered:
Note
For state management, every ATable component uses an instance of a data store class (
TableDataStore
) that has the following features:setCellData
API to update the table's data.Problem:
When a table cell can be edited via both the cell and modal inputs, syncing the cell -> modal action isn't currently straightforward via the API, which breaks two-way reactivity in the table.
Explanation:
The above happens because implementing an
ATable
component in a file doesn't give you easy access to the data store (the unique class instance ID isn't exposed), which means trying to use thesetCellData
API in that file is a hassle.Possible solutions:
I think there's multiple iterations that can happen to fix this issue, some of which include:
ATable
can expose the data store class after initialization. Vue has adefineExpose
API that can let parent components access attributes inside theATable
component (tableData
, for our purpose here).provide
/inject
/expose
.ATable
(differentiated using theid
?), or maintaining a shared store which can hold all table states simultaneously. Either case would also work in parallel with other stores defined in the future inside the Stonecrop context.Example using exposed attributes (doesn't work perfectly, but this should be useful for the concept atleast 😅):
The text was updated successfully, but these errors were encountered: