Skip to content
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

Merged
merged 16 commits into from Sep 19, 2019
Merged

Add Automation UI #5622

merged 16 commits into from Sep 19, 2019

Conversation

felixfbecker
Copy link
Contributor

@felixfbecker felixfbecker commented Sep 17, 2019

Adds the UI for the automation 3.8 milestone.

New pages:

  • Global campaigns list
  • Global campaign details list
    • Shows progress bar with status (no historical burndown chart yet)
    • Lists changesets (no add functionality yet, need to use API)
    • No delete, edit yet
  • Global new campaign form (with dropdown for namespace)

I am using React hooks for all components, and a new hook for Observables.

image

@codecov
Copy link

codecov bot commented Sep 17, 2019

Codecov Report

Merging #5622 into master will increase coverage by 0.01%.
The diff coverage is 70.37%.

@@            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
Impacted Files Coverage Δ
web/src/routes.tsx 17.14% <ø> (ø) ⬆️
cmd/frontend/internal/app/jscontext/jscontext.go 3.03% <0%> (-0.05%) ⬇️
pkg/conf/computed.go 24.51% <0%> (-0.82%) ⬇️
web/src/nav/NavLinks.tsx 81.81% <100%> (ø) ⬆️
web/src/util/useObservable.ts 100% <100%> (ø)
web/src/enterprise/campaigns/icons.ts 100% <100%> (ø)
web/src/components/LinkWithIconOnlyTooltip.tsx 50% <50%> (ø)
...terprise/campaigns/global/nav/CampaignsNavItem.tsx 50% <50%> (ø)
... and 2 more

@lguychard lguychard requested a review from a user September 17, 2019 06:50
@tsenart
Copy link
Contributor

tsenart commented Sep 17, 2019

@felixfbecker: Great! Are there any gaps in the backend that we need to fill still to fully integrate with this?

@felixfbecker
Copy link
Contributor Author

This branch is fully functional, but uses workarounds for API deficiencies, e.g.

  • Query.viewerNamespaces missing
  • Namespace.campaigns missing

@tsenart
Copy link
Contributor

tsenart commented Sep 17, 2019

@felixfbecker: Are those two everything? Or anything else missing?

@tsenart
Copy link
Contributor

tsenart commented Sep 17, 2019

I couldn't find anything about Query.viewerNamespaces in RFC28. Can you help us with more details about it please?

@felixfbecker
Copy link
Contributor Author

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.

@tsenart
Copy link
Contributor

tsenart commented Sep 17, 2019

RFC28 doesn't define any APIs

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?

@felixfbecker
Copy link
Contributor Author

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).

@tsenart
Copy link
Contributor

tsenart commented Sep 17, 2019

I would propose that future API design and review for milestones is done up front in an RFC or PR (with just the schema).

👍

@tsenart
Copy link
Contributor

tsenart commented Sep 17, 2019

@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.

Copy link
Contributor

@lguychard lguychard left a 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?

import { useEffect, useState, useMemo } from 'react'
import { Observable, Observer, Subject } from 'rxjs'

export function useObservable<T>(observable: Observable<T>, deps: readonly unknown[]): T | undefined {
Copy link
Contributor

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?

Copy link
Contributor Author

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> =>
Copy link
Contributor

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?

Copy link
Contributor Author

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)

@felixfbecker
Copy link
Contributor Author

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?

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.

@felixfbecker felixfbecker added this to the 3.8 milestone Sep 18, 2019
@felixfbecker felixfbecker added this to Needs review in Web Team :: Current iteration via automation Sep 18, 2019
Web Team :: Current iteration automation moved this from Needs review to Reviewer approved Sep 19, 2019
@felixfbecker felixfbecker merged commit f05ac74 into master Sep 19, 2019
Web Team :: Current iteration automation moved this from Reviewer approved to Done Sep 19, 2019
@felixfbecker felixfbecker deleted the automation-ui branch September 19, 2019 12:02
lguychard pushed a commit that referenced this pull request Sep 19, 2019
@chrispine chrispine added the batch-changes Issues related to Batch Changes label Aug 27, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
batch-changes Issues related to Batch Changes
Projects
No open projects
Development

Successfully merging this pull request may close these issues.

None yet

5 participants