@@ -595,8 +595,7 @@ class UserDatasetDetail extends React.Component<DetailViewProps> {
595595 key : 'download' ,
596596 name : 'Download' ,
597597 width : '130px' ,
598- // FIXME: this property is not defined in MesaColumn, and this style is not actually being applied
599- // headingStyle: { textAlign: 'center' },
598+ headingStyle : { textAlign : 'center' } ,
600599 renderCell ( ) {
601600 const downloadServiceAvailable = 'getUserDatasetFiles' in wdkService ;
602601 const enableDownload =
@@ -641,11 +640,15 @@ class UserDatasetDetail extends React.Component<DetailViewProps> {
641640
642641 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= */
643642
644- // This is needed to resolve downstream typescript errors.
645- // TypeScript infers that this method returns JSX.Element[].
646- // Some classes extending this will return (JSX.Element | null)[].
647- // The ReactNode type is better suited, here, since it allows for null values.
648- getPageSections ( ) {
643+ // Explicit return type is required for two reasons:
644+ // 1. JSX component constraint: These functions are used as JSX components (<Section />),
645+ // which must return ReactElement | null (not the broader ReactNode type that includes
646+ // undefined, string, number, etc.).
647+ // 2. Hybrid JS/TS compatibility: JavaScript subclasses (like BigwigDatasetDetail.jsx)
648+ // generate .d.ts files from JSDoc annotations. Without an explicit type here,
649+ // TypeScript's inference can conflict with JSDoc-generated types during compilation.
650+ // Subclasses may return sections that are conditionally rendered (null).
651+ getPageSections ( ) : Array < ( ) => React . ReactElement | null > {
649652 return [ this . renderHeaderSection , this . renderFileSection ] ;
650653 }
651654
0 commit comments