Closed nick-stebbings closed 4 months ago
@adaburrows
This is almost complete and I have incorporated the following:
Caveats for the tray config update functionality:
There are still some bugs to be worked out in this which came about as a consequence of treating the tray config as an actual entry type and not a conceptual type that was really just a load of links to a resource definition. Namely:
[x] I now need to rewrite the get_assessment_tray_configs
to iterate through updates to get to the latest tray config for that hash. Currently updates are going through but the tray config list is also showing the old versions as it relies on this function.
[x] Some local component state issues that have come up when changing existing controls to have different details
-We probably need to figure out how to validate that an updated tray config is actually different to the one being updated before submission. This is easy for the name, not so easy for the assessment control configs. Do you want this to rely on a deep equal? Or shall we just leave it for now?
Update: It is basically finished (for demo purposes) However there is STILL a couple of issues
[x] Multi applet stuff is a bit unstable because the Todo applet config probably needs to be defined with totally different dimensions at this point (as the Feed applet was primarily based off its tweaked dimensions, they are very similar and overlap a lot). So basically it depends on #204 which is unresolved for the moment. Update: we have resolved on a call that the mechanism that will feed through the assessment tray configuration to the applets has not been fully fleshed out yet and so they are not expected to work without getting the dimension data from the config.
[x] You can update.. but you can't update an update and get the expected results from get_assessment_config_trays
(i.e. the listed trays page) ..
So I obviously didn't test fully enough, and the helper function I introduced is not doing what I expected (get_latest_assessment_tray
). I thought it would find the latest update from a link target entry hash (as I am not creating links for the updates). The solution is to make it recursive. Oddly I think I wrote it like that originally but had to change it to take an entry hash not an action hash. Then when trying to get it to compile must have switched back to an interative (but not complete) solution. So I can fix it when I get back. It works for n=1 :D
This branch has the launcher in good shape to demo from the Feed applet first, probably. And with the odd hard reload if something goes wrong.
@adaburrows Update: As a follow up to our Discord call, both of the above issues are now sorted, because
The todo applet will not work with multi-applet functionality without being hard coded with dimensions (currently) - so you have to always create those dimensions that come from the configuration. But -- it will work on its own, if you install it first.
This means now you can actually use Todo applet or Feed applet to begin with and you will have no issues, all the assessment tray config setups you create (and subsequent updates) will be ok as long as you use them in line with the config. It is only when you try to add a second applet that you get problems.
The recursive function works now and is included, so all existing functionality has been retained after rewriting the backend code for the main feature (named assessment tray configs with updates).
You should be able to merge this now, once I resolve conflicts (I will do this now).
Update: all done, this will merge now.
Zome code and testing for the four zome functions that now comprise the widgets crate:
set_default_assessment_tray_config_for_resource_def
get_default_assessment_tray_config_for_resource_def
set_assessment_tray_config
get_assessment_tray_config
@adaburrows perhaps we should combine this with 'de-widgetizing' the other type/file names? If so we need to decide what to swap out 'assessment_widget' with.
EDIT: this PR will now incorporate all renaming mentioned above and UI for this feature