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 section for deactivated API release notes #413
Conversation
@@ -132,6 +134,7 @@ | |||
"postcss-preset-env": "6.0.6", | |||
"postcss-safe-parser": "4.0.1", | |||
"prettier": "^1.16.4", | |||
"pretty-format": "^26.4.2", |
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.
issue with requiring pretty-format
from @testing-library/react
: testing-library/react-testing-library#694
content: appealsContent, | ||
name: 'Appeals API', | ||
properName: 'Appeals API', | ||
}, | ||
benefits: { | ||
apis: benefitsApis, | ||
buttonText: 'Get Your Key', |
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.
been meaning to take this thingy out for a while. i think it used to be on the home page but hasn't been for like a year
@@ -20,7 +20,7 @@ const getApiDefinitions = () => apiDefs; | |||
const getApiCategoryOrder = () => apiCategoryOrder; | |||
|
|||
const getAllApis = (): IApiDescription[] => { | |||
return Object.values(apiDefs).flatMap((category: IApiCategory) => category.apis); | |||
return Object.values(getApiDefinitions()).flatMap((category: IApiCategory) => category.apis); |
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.
wanted not to reference apiDefs
directly in multiple places. need to prepare to use a real database and corresponding data repository layer for these definitions in the future.
These changes have been deployed to an S3 bucket. A build for each environment is available: |
@@ -0,0 +1,136 @@ | |||
import AlertBox from '@department-of-veterans-affairs/formation-react/AlertBox'; |
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.
renamed this file to get away from vague use of the language of "page"
… rule is disabled entirely
const ReleaseNotesCardLinks = (props: ReleaseNotesCardLinksProps) => { | ||
const { apiCategory, categoryKey, flagName } = props; | ||
const flags: { [apiId: string]: boolean } = getFlags()[flagName]; | ||
const apis: IApiDescription[] = apiCategory.apis.filter(api => flags[api.urlFragment]); |
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.
we can't use Flag
for this because we only want to show these card links if there is more than one API that will actually be shown on the page, not more than one API in the category, period. if the category has 4 APIs but 3 of them are disabled or deactivated, we don't want this component to return anything. getFlags()
is a good substitute for <Flag />
, now that it's public.
These changes have been deployed to an S3 bucket. A build for each environment is available: |
@Eallan919 thanks for the catch! i think that whole release note should actually be update so it's one line in the markdown file and wraps properly... hmm |
These changes have been deployed to an S3 bucket. A build for each environment is available: |
@@ -8,3 +8,4 @@ REACT_APP_TRY_IT_OUT_ENABLED=false | |||
REACT_APP_SENTRY_DSN=https://4409b200977e4429bb210b601439ef0a@developer.va.gov/sentry/17 | |||
REACT_APP_SENTRY_RELEASE=$SENTRY_RELEASE | |||
REACT_APP_SHOW_TESTING_NOTICE=false | |||
REACT_APP_ARGONAUT_API_ENABLED=false |
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.
Wondering what this change means as it related to this PR, or is this cleaning up a missing setting?
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.
for other reviewers: the Argonaut API's release notes aren't very meaningful because they're from an earlier iteration of the release notes where we were less consistent about updating them. as a result, when we decided to show release notes for deactivated APIs, UX asked us to hide those, for now at least. you can see the release notes in the source file or in the dev and staging review instances. (i'm choosing to leave it on by default for those other environments - i don't want to set a precedent for getting rid of inconvenient things from deactivated APIs wholesale by marking them disabled in addition to deactivated.)
These changes have been deployed to an S3 bucket. A build for each environment is available: |
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.
This is good. I have a couple questions, probably mostly because I'm new. There is language on two tests that I think could be reworded more explicitly. I'm also unsure about the ReleaseNotes Route, render/component attributes. Someone that knows the app more would be better to look at that specific piece.
I don't see anything that needs changed right away but don't want to approve until I know about that React Route component render/component stuff. - granted, I could probably approve. Even if it should be the other way I don't see it breaking anything.
className?: string; | ||
description?: string; | ||
halo?: string; | ||
header: string; | ||
id?: string; | ||
containerId?: string; |
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.
I didn't know optional properties were a thing until now. That's neat.
@@ -3,32 +3,27 @@ import * as React from 'react'; | |||
|
|||
import './PageHeader.scss'; | |||
|
|||
interface IPageHeaderProps { | |||
interface PageHeaderProps { |
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.
Is moving away from the 'I' prefix something we're explicitly doing as a whole project?
I agree with the change but curious if this was a high level shared decision. - so when I make my first code changes I can follow the right convention.
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, definitely - should've left a comment on this, because this question has come up before recently and there's a big difference between a yes and no answer. yes, we decided to go with no prefix around the time the backend got stood up as its own Node app, and we decided to be consistent across the front and back end. apologies for making an assumption here!
@@ -33,6 +45,11 @@ export default () => { | |||
</Flag> | |||
); | |||
})} | |||
{deactivatedCategory.apis.length > 0 && ( | |||
<CardLink name={deactivatedCategory.name} url="/release-notes/deactivated"> | |||
This is a repository for deactivated APIs and related documentation and release notes. |
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.
When this says 'this is a repository', is that like a git repository that should be linked, or is it meaning the card link is a place where they can find all deactivated apis in the developer-portal webapp?
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.
good question - it's the latter. sometimes the release notes link out to PRs and whatnot, but this isn't intended to be in the technical version control sense.
} | ||
}); | ||
}; | ||
interface SideNavCategoryEntryProps { |
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.
I like the code clean up with this.
expect(cardLink.getAttribute('href')).toBe('/release-notes/sports'); | ||
}); | ||
|
||
it('does not render a card for a disabled category', () => { |
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.
I like this test. I feel like this kind of check is the kind that would usually get left out. Thanks for adding it!
).toBeNull(); | ||
}); | ||
|
||
it('has a card link for deactivated APIs if there are any', () => { |
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.
Maybe rephrase this to 'has a card link for deactivated APIs when one exists'? I was trying to figure out if this test was somehow covering both conditions.
path="/release-notes/:apiCategoryKey" | ||
component={CategoryReleaseNotesPage} | ||
path="/release-notes/deactivated" | ||
render={DeactivatedReleaseNotes} |
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.
I am just now looking up the difference between using render and component in a Route path. I'd like a second set of eyes on this to say if it's good. - or if you could explain it for me why we are good to use render on DeactivedReleaseNotes here but use component for CategoryReleaseNotes below.
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.
wow, great catch. i'm not really sure when/why i made this render
, it should probably be component
. i believe they're functionally equivalent in this case, but render
is more frequently used for inline functions.
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.
When I was looking it up I saw something about one of them making new instances or something, but I'm not sure specifics or how these components are used so not sure at all. haha.
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.
yeahhh fair, i think the differences are pretty hard to parse out. i think the idea is that <Route component={() => <div>hello!</div>} />
will mount a new component each time it gets rendered because of how it treats that function internally (maybe because it's anonymous? i don't know either, would have to research it more to get what's happening there). but if you do <Route render={() => <div>hello!</div>} />
, React Router treats it differently and therefore handles that case.
expect(queryByRole(sideNav, 'link', { name: 'Sports API' })).toBeNull(); | ||
}); | ||
|
||
it('has an entry for deactivated APIs', () => { |
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.
Similar to ReleaseNotesOverviewTest this could be reworded to be something like 'has an entry for deactived APIs when there are deactived APIs'
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.
yup, that's a good point, thanks! will clarify that language
These changes have been deployed to an S3 bucket. A build for each environment is available: |
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.
Looks good. The previous reviews were addressed.
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.
LGTM - Good Job on this!
Description
completes API-1790. design ticket is API-1495.
adds a new section showing release notes for deactivated APIs. tests have been added using React Testing Library in support of API-1317.
Process
Requested feedback