Open nick-stebbings opened 10 months ago
updateAppletConfig
is actually just a store update, no entry is created and so this will be an outlier. Maybe the method needs renaming to make this clear?
for getAssessmentsForResources
.. currently we are getting back a Record<EntryHashB64, Array<Assessment>>>
. Can you please clarify what is the requested return type for this instead? If we are needing an array of EntryRecord<Assessment>
as the value of the Record, it will mean changes to multiple zome functions so I just wanted to clarify first.
for setAssessmentWidgetTrayConfig
, I assume this may as well wait for getAssessmentWidgetTrayConfig
to be changed as you described in the comment?
All of the above also invalidates the README for sensemaker client. It was already quite out of date, shall we set that up as a separate task involving changing the reported return types?
@adaburrows If you can clarify the above few questions I can move to close off this issue.
Sensemaker store methods should consistently return similar data structures unless there is a good reason to not return that data structure. The basic unit should be a
EntryRecord<X>
. If it's async, it should be aPromise<EntryRecord<X>>
. If there are multiple objects, it should be aPromise<Array<EntryRecord<X>>>
Please update:
createRange
createDimension
createResourceDef
createAssessment
getAssessmentsForResources
— this will require changing the demo apps and maybe some of the delegate code.createMethod
runMethod
createOutputDimensionAndMethodAtomically
—{ outputDimension: EntryRecord<Dimension>, method: EntryRecord<Method> }
— eventually, we will need to be able to refer to AssessmentWidgetTrayConfigs as standalone objects, so the return type will be more complicated, likegetAssessmentWidgetTrayConfig
Promise<{ assessmentTray: EntryRecord<AssessmentTrayConfig>, configBlocks: Array<AssessmentWidgetBlockConfig> }>
. However, we need to scope this work as a separate task.setAssessmentWidgetTrayConfig
— should return the same type asgetAssessmentWidgetTrayConfig
. (for now just remove the 'return true')updateAppletConfig
~~registerWidget
— This has an interesting interplay with other objects and it makes the most sense to keep it the way it is for now. However I can see arguments for changing it over since we seem to only be using the values from it anyway. If we do change it over it will mean we need to write a helper function to getgetRegisteredWidgets
Array<X>
fromArray<EntryRecord<X>>
. In the future, we may also want to keep the hashes around so we can pass them back to Holochain so we don't have to delete every link and recreate it every time (though we would also need to make a way to enforce the ordering of objects).