Repository navigation
feat(content-sidebar): add archived date to content preview sidebar - #3625
mergify[bot] merged 22 commits into
Conversation
|
|
||
| const { accessStats, accessStatsError, file, fileError, isLoadingAccessStats }: State = this.state; | ||
|
|
||
| const shouldShowArchivedAt = isFeatureEnabled(features, 'details.archivedAt.enabled'); |
There was a problem hiding this comment.
I feel like this should be moved all the way to down the bottom where the archivedAt is actually used, if you put a tenary at this level to decide if it should have the archivedAt or not because you wont know if the archivedAt is actually present but the split is off or its undefined when its retrieved from the server or if the split is on and the archivedAt is undefined
There was a problem hiding this comment.
Seems better. Just to make sure - you mean move features all the way down to ItemProperties.js or should I just move the shouldShowArchivedAt as a prop?
e172d3b to
8079044
Compare
| archivedAt: null, | ||
| features: { | ||
| details: { | ||
| archivedAt: { | ||
| enabled: false, | ||
| }, | ||
| }, | ||
| }, | ||
| }); | ||
|
|
||
| expect(wrapper).toMatchSnapshot(); | ||
| }); | ||
|
|
||
| test('should not render archived date when feature is not set', () => { | ||
| const wrapper = getWrapper({ | ||
| archivedAt: null, |
There was a problem hiding this comment.
I think we should actually supply a archivedAt here so we are certain that the tests are passing because the feature is off or undefined. from reading the test itself, we dont know if its not rendering because archivedAt is null or feature is null/undefined.
|
|
||
| ItemProperties.propTypes = { | ||
| /** the datetime this item was archived, accepts any value that can be passed to the Date() constructor */ | ||
| archivedAt: PropTypes.oneOfType([PropTypes.number, PropTypes.string]), |
There was a problem hiding this comment.
can it actually be a number?
There was a problem hiding this comment.
Changed to string
There was a problem hiding this comment.
Changed again since we're probably are going to be using unix epoch timestamps
| {hasVersions && <SidebarVersions file={file} onVersionHistoryClick={onVersionHistoryClick} />} | ||
| <SidebarFileProperties | ||
| archivedAt={archivedAt} | ||
| file={file} |
There was a problem hiding this comment.
It seems more appropriate for archived_at to be a field on the File model.
|
|
||
| export default ItemProperties; | ||
| export { ItemProperties as ItemPropertiesComponent }; | ||
| export default withFeatureConsumer(ItemProperties); |
There was a problem hiding this comment.
Do we have a hook? If so, let's use it; if not, let's create one.
| url, | ||
| }) => { | ||
| const descriptionId = uniqueid('description_'); | ||
| const shouldShowArchivedAt = isFeatureEnabled(features, 'details.archivedAt.enabled'); |
There was a problem hiding this comment.
Can we update the endpoint to not return the value if the feature isn't enabled yet, instead?
b271c87 to
2457413
Compare
| <ItemProperties | ||
| archivedAt={Number(getProp(file, FIELD_METADATA_ARCHIVE)?.archiveDate) * 1000} |
There was a problem hiding this comment.
Right now we plan to store unix epoch timestamps as strings in our template, but we're discussing changing their type to number.
Just in case we don't change it - is this conversion okay if we decide to store them as strings?
There was a problem hiding this comment.
Also I will need to make sure whether they will be stored in seconds or milliseconds
There was a problem hiding this comment.
Our linter may complain about using a static built-in method like this. If so, use parseInt(value, 10) instead.
That said, we should handle formatting/display within ItemProperties rather than here, as well as handling non-number values better.
There was a problem hiding this comment.
Seems good with linter, I will wait with fixes for after we finalize type and format in which we store archiveDate in our metadata template.
There was a problem hiding this comment.
But also - do we need something better than js Date() for handling this?
If so, I can try implementing something here, if you tell me which cases you need handled.
But if not, shouldn't passing correct date format be responsibility of parent component using ItemProperties?
There was a problem hiding this comment.
I slightly refactored conversion here, now it passes undefined to prop when we don't have it metadata. My team finalized discussions and we'll have unix epoch timestamp in seconds stored as a string, so this should be correct conversion
| const SIDEBAR_FIELDS_TO_FETCH = [ | ||
| const SIDEBAR_FIELDS_TO_FETCH: Array<string> = [ |
There was a problem hiding this comment.
Hm. I'm not seeing this error locally. Flow is pretty terrible, but it should be able to infer one string array from another. Are you using the local Flow binary installed with the project? If so, maybe try removing the type annotations to see if it was a temporary issue?
There was a problem hiding this comment.
Removed type annotation from SIDEBAR_FIELDS_TO_FETCH, but left one on SIDEBAR_FIELDS_TO_FETCH_ARCHIVE, without this one the flow error was still showing
jstoffan
left a comment
There was a problem hiding this comment.
Approach LGTM. Left some feedback on a few other touch-ups that are needed.
| import type { BoxItem } from '../../common/types/core'; | ||
| import type { FeatureConfig } from '../common/feature-checking'; | ||
| import './DetailsSidebar.scss'; | ||
| import { isFeatureEnabled, withFeatureConsumer } from '../common/feature-checking'; |
There was a problem hiding this comment.
Let's move this line above the SCSS and type imports.
| className="loading-indicator-wrapper " | ||
| > | ||
| <ItemProperties | ||
| archivedAt={NaN} |
There was a problem hiding this comment.
We should handle cases where the value isn't a number by hiding the line item.
There was a problem hiding this comment.
Fixed after conversion change
| jest.mock('../SidebarClassification', () => 'SidebarClassification'); | ||
| jest.mock('../SidebarContentInsights', () => 'SidebarContentInsights'); | ||
| jest.mock('../../common/feature-checking', () => ({ | ||
| ...jest.requireActual('../../common/feature-checking'), |
There was a problem hiding this comment.
Do we need the rest of the module or can we just mock the whole thing?
jest.mock('../../common/feature-checking');
There was a problem hiding this comment.
It was not needed, fixed here and in ContentSidebar.test.js
| <ItemProperties | ||
| archivedAt={Number(getProp(file, FIELD_METADATA_ARCHIVE)?.archiveDate) * 1000} |
There was a problem hiding this comment.
Our linter may complain about using a static built-in method like this. If so, use parseInt(value, 10) instead.
That said, we should handle formatting/display within ItemProperties rather than here, as well as handling non-number values better.
jstoffan
left a comment
There was a problem hiding this comment.
Thanks for working to refine the solution!
| const SIDEBAR_FIELDS_TO_FETCH = [ | ||
| const SIDEBAR_FIELDS_TO_FETCH: Array<string> = [ |
There was a problem hiding this comment.
Hm. I'm not seeing this error locally. Flow is pretty terrible, but it should be able to infer one string array from another. Are you using the local Flow binary installed with the project? If so, maybe try removing the type annotations to see if it was a temporary issue?
This reverts commit 11d68f5.
9505cdb to
0aac903
Compare
| exports[`elements/content-sidebar/SidebarFileProperties render() should render ItemProperties for anonymous uploaders 1`] = ` | ||
| <LoadingIndicatorWrapper> | ||
| <ItemProperties | ||
| archivedAt={1726832355000} |
There was a problem hiding this comment.
Ideally, all our endpoints should use the same format for dates. We can address that as a separate change, though, if needed.

Adding archive date to details sidebar. When feature is enabled it's fetched along rest of the file information from global metadata template
archivedItemTemplate