-
Notifications
You must be signed in to change notification settings - Fork 57
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[4354] Add support for cursor based pagination in table view DSL #4355
base: master
Are you sure you want to change the base?
Conversation
Bug: #4354 Signed-off-by: Florian ROUËNÉ <[email protected]>
<parent> | ||
<groupId>org.springframework.boot</groupId> | ||
<artifactId>spring-boot-starter-parent</artifactId> | ||
<version>3.3.3</version> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sidenote: there's a PR upgrading Spring Boot currently being reviewed, one way or another this will have to be updated depending on which PR gets merged first.
if (elementDescription.getDomainType() == null || elementDescription.getDomainType().isBlank()) { | ||
return new PaginatedData(candidates, false, false, candidates.size()); | ||
PaginatedData paginatedResult; | ||
if (elementDescription.getSemanticCandidatesExpression() != null && !elementDescription.getSemanticCandidatesExpression().isBlank()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you convert one of the two Papaya example to use the view DSL because there's something I don't understand here. How could you choose to perform this for the specifier?
Is it possible for us to support a DomainType
in the view DSL row semantic elements expression?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As I said on the ADR for the pagination back in October
I don't see how RowDescription#domainType
or RowDescription#preconditionExpression
can still exist today. So unless I missed something, TableElementDescription
should be removed since it does not make much sense for both CellDescription
and RowDescription
to share a common parent (that's an useless abstraction). On top of that both RowDescription#domainType
and RowDescription#preconditionExpression
should be deleted too because we will never be able to guess how they should behave instead of the specifier as said in October.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I keep them to provide a flawed solution if someone use domainType and semanticCandidatesExpression.
I will removed them
Bug: #4354
Pull request template
General purpose
What is the main goal of this pull request?
Project management
priority:
andpr:
labels been added to the pull request? (In case of doubt, start with the labelspriority: low
andpr: to review later
)area:
,difficulty:
,type:
)CHANGELOG.adoc
been updated to reference the relevant issues?CHANGELOG.adoc
? (Including changes in the GraphQL API)CHANGELOG.adoc
? For example indoc/screenshots/2022.5.0-my-new-feature.png
Architectural decision records (ADR)
[doc]
?CHANGELOG.adoc
?Dependencies
CHANGELOG.adoc
?CHANGELOG.adoc
?Frontend
This section is not relevant if your contribution does not come with changes to the frontend.
General purpose
Typing
We need to improve the typing of our code, as such, we require every contribution to come with proper TypeScript typing for both changes contributing new files and those modifying existing files.
Please ensure that the following statements are true for each file created or modified (this may require you to improve code outside of your contribution).
useMutation<DATA_TYPE, VARIABLE_TYPE>(…)
useQuery<DATA_TYPE, VARIABLE_TYPE>(…)
useSubscription<DATA_TYPE, VARIABLE_TYPE>(…)
useMachine<CONTEXT_TYPE, EVENTS_TYPE>(…)
useState<STATE_TYPE>(…)
?.
(if the GraphQL API specifies that a field cannot benull
, do not treat it has potentiallynull
for example)let diagram: Diagram | null = null;
)Backend
This section is not relevant if your contribution does not come with changes to the backend.
General purpose
Architecture
Review
How to test this PR?
Please describe here the various use cases to test this pull request