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
I realized from looking at the open-source Canvas iOS repo, that there's a simpler way of implementing decoding, saving, etc. into one function:
For each model, we create a DTO struct. So for Quiz we have QuizDTO. This will be used to seamlessly decode from an API response. We'll also have a DTO associated type.
We'll have a flush (or save) method in each model which takes in the corresponding DTO. It will find the associated @Model entry and return it. It effectively handles merging and inserting into a specific model context. The model context will probably be per user, flush shouldn't decide.
Because of the above, I'll remove the Codable conformance from Cacheable. We'll also remove the merge functions since above handles it.
We'll experiment with @Relationship types, but parentId approach still works really well. I'm unsure about making parentId an array, I'll think about use cases for that before deciding. Otherwise it's redundant.
Relevant Resources
(Feature Owner, Developer) Attach links to resources such as Figma files, technical documentation, etc.
(Developer) Add child issues (technical or high level) that will help you modularize your implementation this feature.
Task 1 ...
Task 2 ...
When beginning work on a task, click on the ... button to the right of the task and click on Convert to Issue to create a child issue linked to this parent issue.
Implementation Plan (optional)
(Developer) Write an implementation plan here, or attach a link to a document containing it.
The text was updated successfully, but these errors were encountered:
Description
I realized from looking at the open-source Canvas iOS repo, that there's a simpler way of implementing decoding, saving, etc. into one function:
Quiz
we haveQuizDTO
. This will be used to seamlessly decode from an API response. We'll also have a DTO associated type.flush
(orsave
) method in each model which takes in the corresponding DTO. It will find the associated@Model
entry and return it. It effectively handles merging and inserting into a specific model context. The model context will probably be per user,flush
shouldn't decide.Codable
conformance fromCacheable
. We'll also remove themerge
functions since above handles it.@Relationship
types, butparentId
approach still works really well. I'm unsure about making parentId an array, I'll think about use cases for that before deciding. Otherwise it's redundant.Relevant Resources
(Feature Owner, Developer) Attach links to resources such as Figma files, technical documentation, etc.
Child Issues
(Developer) Add child issues (technical or high level) that will help you modularize your implementation this feature.
When beginning work on a task, click on the
...
button to the right of the task and click onConvert to Issue
to create a child issue linked to this parent issue.Implementation Plan (optional)
(Developer) Write an implementation plan here, or attach a link to a document containing it.
The text was updated successfully, but these errors were encountered: