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
Add Automation UI #5622
Add Automation UI #5622
Conversation
Codecov Report
@@ Coverage Diff @@
## master #5622 +/- ##
==========================================
+ Coverage 47.57% 47.58% +0.01%
==========================================
Files 757 761 +4
Lines 46052 46078 +26
Branches 2749 2752 +3
==========================================
+ Hits 21907 21925 +18
- Misses 22081 22089 +8
Partials 2064 2064
|
@felixfbecker: Great! Are there any gaps in the backend that we need to fill still to fully integrate with this? |
This branch is fully functional, but uses workarounds for API deficiencies, e.g.
|
@felixfbecker: Are those two everything? Or anything else missing? |
I couldn't find anything about |
It's defined in RFC20 (RFC28 doesn't define any APIs) and also implemented in Quinn's prototype branch. It's needed to list the possible namespaces a user can pick to create a campaign under. |
c642105
to
5025fde
Compare
RFC28 is what we're working towards in this iteration, right? It certainly defines APIs, as we implement them to support the specified functionality. We've been adding you as a reviewer so that you could integrate the frontend code on an on-going basis, as well as provide valuable feedback. What can we do going forward to get on the same page more easily? |
Yes, but it only talks about product/UI requirements, not GraphQL fields. I thought we were sticking to RFC20 for the fields that are needed to achieve RFC28, but it wasn't obvious which fields we need. In retrospect, I should have made a list of the subset of fields from RFC20 that are needed for RFC28. GraphQL is a client-oriented API language, and I believe it is important to design the API from the client's perspective, not from the backend's perspective with post-merge reviews (that may then be discarded because now more effort is needed to change anything, like database migrations etc). The biggest mistake was probably simply that we skipped a8n sync last week (I missed that no different time was setup after the cancellations) where we could have uncovered these misalignments. I would propose that future API design and review for milestones is done up front in an RFC or PR (with just the schema). |
👍 |
@felixfbecker: Can you please follow up with a PR that changes the schema to add the missing functionality in the scope of RFC20 and these frontend changes? We can discuss there next steps. |
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.
Great stuff, I love how little boilerplate there is with hooks +useObservable()
compared to how our components have traditionally been written.
I'm noticing that only useObservable()
has tests. I'm assuming this is because you still expect a lot of changes in the new components in the near future? What is your planned strategy for testing these new components / new functionality?
web/src/util/useObservable.ts
Outdated
import { useEffect, useState, useMemo } from 'react' | ||
import { Observable, Observer, Subject } from 'rxjs' | ||
|
||
export function useObservable<T>(observable: Observable<T>, deps: readonly unknown[]): T | undefined { |
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 add docstrings for useObservable()
and useEventObservable()
?
Not blocker: Also curious whether we could create a new eslint rule based on react-hooks/exhaustive-deps
, that would give accurate warnings on missing useObservable()
deps?
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.
Yeah, this might be something to discuss with React to check deps
parameters on custom hooks too. However, as I was writing the docblock, I realized that it is probably better to use the observable
here as dep for useEffect()
, and let the caller make sure it doesn't change unintentionally by using useMemo()
. useMemo()
will then be checked correctly (although we cannot check that useMemo()
is used without a custom rule).
import { LoadingSpinner } from '@sourcegraph/react-loading-spinner' | ||
import { CampaignsIcon } from '../icons' | ||
|
||
export const createCampaign = (input: GQL.ICreateCampaignInput): Observable<GQL.ICampaign> => |
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.
Instinctively, I would've injected createCampaign()
and other helpers calling queryGraphQL()
/ mutateGraphQL()
) through Props
so that they could be mocked in tests. Thoughts on doing that?
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.
Yeah, I will do that once I'm adding tests (won't be difficult to refactor)
Yes, I didn't write snapshots or e2e tests yet because they wouldn't help rn catching regressions and would hinder the refactors that will be needed to implement the next milestone of features. Right now I need to test everything manually anyway and it's small enough that I have a good handle on it. I do plan to test everything as it gets more stable. I added tests for the hooks because I expect them to stay like this (at least the signatures) and tests gave me more confidence in them working correctly. |
96e5052
to
a5c67be
Compare
Adds the UI for the automation 3.8 milestone.
New pages:
I am using React hooks for all components, and a new hook for Observables.