daiquiri-ui merge requestshttps://gitlab.esrf.fr/ui/daiquiri-ui/-/merge_requests2024-03-28T16:30:21+01:00https://gitlab.esrf.fr/ui/daiquiri-ui/-/merge_requests/677Allow to fetch ndarrays2024-03-28T16:30:21+01:00Valentin VallsAllow to fetch ndarraysThe scan data fetcher was designed for 1d channel and live update.
This PR allow to use the same server to fetch nd-data channels.
For basic use cases it's not a problem.
This should only have impact on tomo services.The scan data fetcher was designed for 1d channel and live update.
This PR allow to use the same server to fetch nd-data channels.
For basic use cases it's not a problem.
This should only have impact on tomo services.daiquiri/2024.devValentin VallsValentin Vallshttps://gitlab.esrf.fr/ui/daiquiri-ui/-/merge_requests/675Draft: hardware: Make sure the properties are set as they come2024-03-27T15:29:00+01:00Valentin VallsDraft: hardware: Make sure the properties are set as they comeWithout that the properties which are dict are recursively updated.
As result there is no way to remove any keys.
That's not what we want here.
This PR is a bit ugly, but i am afraid we have to rework our esrf redux provider to be abl...Without that the properties which are dict are recursively updated.
As result there is no way to remove any keys.
That's not what we want here.
This PR is a bit ugly, but i am afraid we have to rework our esrf redux provider to be able to make it better.daiquiri/2024.devValentin VallsValentin Vallshttps://gitlab.esrf.fr/ui/daiquiri-ui/-/merge_requests/672Draft: allow selection of url for source2024-03-22T10:00:48+01:00Stuart FisherDraft: allow selection of url for sourceUI for https://gitlab.esrf.fr/ui/daiquiri/-/merge_requests/750UI for https://gitlab.esrf.fr/ui/daiquiri/-/merge_requests/750Stuart FisherStuart Fisherhttps://gitlab.esrf.fr/ui/daiquiri-ui/-/merge_requests/670Draft: Scale sample images based on zoom, hide images out of view2024-03-22T10:01:07+01:00Stuart FisherDraft: Scale sample images based on zoom, hide images out of viewStuart FisherStuart Fisherhttps://gitlab.esrf.fr/ui/daiquiri-ui/-/merge_requests/640Upgrade to React 182023-12-11T10:08:05+01:00Axel BocciarelliUpgrade to React 18Following !639 and as discussed yesterday with @sfisher, I'm opening this MR to upgrade to React 18 and investigate the consequences together a bit more.
- From the Daiquiri UI side of things, **it's looking great**, but I will leave it...Following !639 and as discussed yesterday with @sfisher, I'm opening this MR to upgrade to React 18 and investigate the consequences together a bit more.
- From the Daiquiri UI side of things, **it's looking great**, but I will leave it to you guys to test it thoroughly of course.
- From the Docusaurus side of things, it's looking decent. Docusaurus has only recently released an alpha version to support React 18. I've upgraded to this alpha version and I'm not seeing any major issue, but of course it remains an alpha version, and there are a bunch of peer deps warnings... so not ideal, but maybe not a blocker.
- From the tests side of things, it's less great... Contrary to my previous attempts, I decided to not upgrade Jest or any of the Testing Library packages. This, in itself, is far from ideal... However, it does have the merit of limiting the number of failing tests. I've skipped the few that do fail for now:
- those that test hooks, as the `@testing-library/react-hooks` has been deprecated and replaced with a `renderHook` function in `@testing-library/react` – unfortunately, the API is not exactly the same (missing `waitForNextUpdate`) and requires upgrading `@testing-library/react`, which breaks most of the other tests;
- those that use `ReactDOM.render` and expect no error to be logged (since React throws an error when this legacy API is used).Axel BocciarelliAxel Bocciarellihttps://gitlab.esrf.fr/ui/daiquiri-ui/-/merge_requests/639Make a bit more progress towards upgrading to React 182023-12-11T09:50:04+01:00Axel BocciarelliMake a bit more progress towards upgrading to React 18This supersedes !450.
I spent the last couple of days trying, once again, to upgrade to React 18... but once again I can't get passed all the failing tests. I tried setting up Jest independently from Create React App in order to use the...This supersedes !450.
I spent the last couple of days trying, once again, to upgrade to React 18... but once again I can't get passed all the failing tests. I tried setting up Jest independently from Create React App in order to use the latest version; I tried installing all the latest version of the Testing Library packages; I tried refactoring various things in the app; ... I tried sooo many workarounds, but every time I change something, something else breaks for no clear reason. :disappointed:
There's definitely a combination of:
- Jest/Testing Library/React struggling to handle asynchronicity in a JSDOM environment — one example I encountered is components rendered with `React.lazy()` getting stuck on "Loading..."
- tests leaking into one another — i.e. tests that pass when run on their own but not together (maybe something to do with all the singletons used for rendering the app, like `Start` and `RestService` and/or with the Redux/zustand stores or `local/sessionStorage` not being cleared properly :shrug:)
In this MR, I bring some of the changes from !450 and fix various issues (notably with typing) that popped up at various times along my quest. I also upgrade two libraries mentioned in #103 that are now compatible with React 18.
We should have a chat about where to go next. We need to get past this one way or another so we can move forward in H5Web, but also for the long-term health of the Daiquiri UI project.Axel BocciarelliAxel Bocciarellihttps://gitlab.esrf.fr/ui/daiquiri-ui/-/merge_requests/625Draft: Test props with className2023-07-07T09:00:12+02:00Valentin VallsDraft: Test props with classNameTest to check docusaurus parsingTest to check docusaurus parsingValentin VallsValentin Vallshttps://gitlab.esrf.fr/ui/daiquiri-ui/-/merge_requests/586Draft: Celery rebase2023-03-27T17:27:49+02:00Stuart FisherDraft: Celery rebaseTodo:
* [ ] refactor to functional components
* [ ] refactor to typescript
* [ ] improve aesthetics on task list
Implemented components
* workerslist => list of workers and running tasks
* executedtaskslist => list of tasks that daiquir...Todo:
* [ ] refactor to functional components
* [ ] refactor to typescript
* [ ] improve aesthetics on task list
Implemented components
* workerslist => list of workers and running tasks
* executedtaskslist => list of tasks that daiquiri has seen being executed (flower like functionality)
![Screenshot_2022-07-26_at_08.11.33](/uploads/dbb63c8ad0a2aff15229d4150076a30c/Screenshot_2022-07-26_at_08.11.33.png)
![Screenshot_2022-07-26_at_08.11.40](/uploads/74d0627bcfffba7f43e09447ffb19f88/Screenshot_2022-07-26_at_08.11.40.png)
![Screenshot_2022-07-26_at_08.12.03](/uploads/08bed56e19fd5906133d0d7a858db3df/Screenshot_2022-07-26_at_08.12.03.png)
![Screenshot_2022-07-26_at_08.12.09](/uploads/838d5f590e4bc77a24300debf88b8ec6/Screenshot_2022-07-26_at_08.12.09.png)Stuart FisherStuart Fisherhttps://gitlab.esrf.fr/ui/daiquiri-ui/-/merge_requests/541Draft: Feature/typescript32023-11-13T16:52:47+01:00Valentin VallsDraft: Feature/typescript3Convert `ArrayTableField` to typescript.
This stuff contains far too much `@ts-expect-error` to my taste.Convert `ArrayTableField` to typescript.
This stuff contains far too much `@ts-expect-error` to my taste.Valentin VallsValentin Vallshttps://gitlab.esrf.fr/ui/daiquiri-ui/-/merge_requests/537Draft: Speedup some hardware stuffs2022-12-01T13:58:13+01:00Valentin VallsDraft: Speedup some hardware stuffsThis PR tries to speed up some stuffs relative to #105
This does not fix the real problem, but just mitigate it for the hardware objects.This PR tries to speed up some stuffs relative to #105
This does not fix the real problem, but just mitigate it for the hardware objects.Valentin VallsValentin Vallshttps://gitlab.esrf.fr/ui/daiquiri-ui/-/merge_requests/475Draft: Dispatch fetch actions only when actually needed2022-09-06T15:37:54+02:00Axel BocciarelliDraft: Dispatch fetch actions only when actually neededOpening as draft to start a discussion.
I'm trying to get rid of these console messages to reduce the noise in development and when running tests:
![image](/uploads/157faea9eabf0767b74db88abc344c05/image.png)
- The line that logs this...Opening as draft to start a discussion.
I'm trying to get rid of these console messages to reduce the noise in development and when running tests:
![image](/uploads/157faea9eabf0767b74db88abc344c05/image.png)
- The line that logs this is here: https://gitlab.esrf.fr/ui/redux-provider/-/blob/master/src/Actions.js#L77
- It gets called when the `promise` function of a namespace's async action returns a falsy value. For instance in `providers/hardward.js` on line 102:
```ts
promise: (payload, state) => {
if (
payload.first &&
(state.ns_hardware.default.fetched ||
state.ns_hardware.default.fetching)
) {
return undefined;
}
return RestService.get('/hardware');
}
```
The purpose of this condition seems to be to avoid fetching hardware objects if they're already fetched or being fetched. To get this behaviour, one has to pass `{ first: true }` as payload to the `FETCH_HARDWARE_default` action. For instance, in `/connect/hardware/Hardware.js`:
```ts
const mapDispatchToProps = (dispatch, own) => {
const { hardware, groups } = own.providers.hardware;
return {
actions: {
fetch: payload => hardware.fetch({ first: true }),
fetchGroups: payload => groups.fetch({ first: true })
}
};
};
```
While it would be easy to just remove the `console.log`, I wonder if the current behaviour of "skipping" an async action like this is the right way to go. I'm thinking that it is perhaps more the Redux Way :tm: to avoid dispatching the action in the first place?
This is what I've attempted to do in this PR. Basically, I'm replicating the `promise` function logic in `/components/hardware/Hardware`. The clear downside is that it takes a lot more boilerplate, since one has to provide the `fetched` and `fetching` props to the component. Here it wasn't too bad since `fetched` was already provided, but in other places like `Synoptic`, it's a bit more work. Also, it means duplicating the same logic in multiple places, which is annoying.
With suspense and a resource fetching/caching library like `rest-hooks`, this kind of problem would not exist, so perhaps it is not worth trying to find a complex solution in the current architecture and better to comment out the `console.log` in `redux-provider`. Let me know what you think.Axel BocciarelliAxel Bocciarellihttps://gitlab.esrf.fr/ui/daiquiri-ui/-/merge_requests/404Draft: example component2022-08-10T10:33:38+02:00Stuart FisherDraft: example componentExample UI for https://gitlab.esrf.fr/ui/daiquiri/-/merge_requests/530Example UI for https://gitlab.esrf.fr/ui/daiquiri/-/merge_requests/530Stuart FisherStuart Fisherhttps://gitlab.esrf.fr/ui/daiquiri-ui/-/merge_requests/284Draft: reprocess2022-06-28T16:03:23+02:00Stuart FisherDraft: reprocesshttps://gitlab.esrf.fr/ui/daiquiri-ui/-/merge_requests/276Draft: work on cleaning up store on logout2023-10-09T16:21:57+02:00Stuart FisherDraft: work on cleaning up store on logouthttps://gitlab.esrf.fr/ui/daiquiri-ui/-/merge_requests/259Draft: Actor button2022-04-21T13:36:18+02:00Stuart FisherDraft: Actor buttonA simple component to launch an actor on click from SampleScans. Supports a simple inline form to set params (or none at all) from the actor Schema. For the future need to also add a way to retrieve params from the store. Also probably s...A simple component to launch an actor on click from SampleScans. Supports a simple inline form to set params (or none at all) from the actor Schema. For the future need to also add a way to retrieve params from the store. Also probably some room to improve the styling of the inline form
![Screenshot_2021-08-17_at_15.33.45](/uploads/768e196e69535e63fb945240b7d439f6/Screenshot_2021-08-17_at_15.33.45.png)
Layout yaml would look something like:
```yaml
component: actorbutton
options:
actor: ct
title: 'CT Update'
params:
exposure: 1
```
And the basic actor in samplescans:
```python
from marshmallow import fields
from daiquiri.core.components import (
ComponentActor,
ComponentActorSchema,
)
from daiquiri.core.hardware.bliss.session import *
class CtSchema(ComponentActorSchema):
enqueue = fields.Bool(default=False)
sampleid = fields.Int()
exposure = fields.Float(required=True, metadata={"title": "Exposure Time"})
class Meta:
uischema = {
"sampleid": {"classNames": "hidden-row", "ui:widget": "hidden"},
"enqueue": {"classNames": "hidden-row", "ui:widget": "hidden"},
# "exposure": {"classNames": "hidden-row", "ui:widget": "hidden"},
}
class CtActor(ComponentActor):
# this is important to stop daiquiri saving metadata associated with this scan
# default is 'experiment'
metatype = None
schema = CtSchema
name = "ct"
def method(self, **kwargs):
lima = config.get("lima_simulator")
ct(kwargs["exposure"], lima)
```
and actor activate in samplescans.yml with
```yaml
component: samplescan
scans:
- actor: exafs
- actor: exafsramp
- actor: scandisplay
- actor: ct
```