Repository navigation
#79 / Library Updates for UI - #80
Conversation
…ome import.meta logic
…ents into 79/bug-fixes-for-modal
There was a problem hiding this comment.
Moved out of utils/elasticMetadataClient
| if (!FileMetaDataSchema.safeParse(indexFileMetadata)) | ||
| console.error(`Error retrieving Index file from Score with object_id: ${fileObjectId}, results may be inaccurate`); | ||
|
|
||
| return { scoreFileMetadata, indexFileMetadata }; |
There was a problem hiding this comment.
Most importantly, FileMetaDataSchema.safeParse(...) ALWAYS is truthy, it returns an object. you want to check FileMetaDataSchema.safeParse(...).success.
Following that, we should be returning the data from the parse result, not the original (untyped) response data:
const metadataParseResult = FileMetaDataSchema.safeParse(indexFileMetadata);
if(!metadataParseResult.success) {
console.error(`Error retrieving Index file from Score with object_id: ${fileObjectId}, results may be inaccurate`);
// return something that indicates our data wasn't available, otherwise the consumer of this function will process data that is the wrong shape and will break.
}
return { scoreFileMetadata, indexFileMetadata: metadataParseResult.data };There was a problem hiding this comment.
Sorry let me revise this, I followed up on some of your previous PR comments then the changes got lost in the shuffle and may have rushed a few revisions
| export const FileMetaDataSchema = zod.object({ | ||
| objectId: zod.string(), | ||
| objectKey: zod.string().optional(), | ||
| objectMd5: zod.string().optional(), | ||
| objectSize: zod.number().optional(), | ||
| parts: zod.array( | ||
| zod.object({ | ||
| md5: zod.string().nullable().optional(), | ||
| offset: zod.number().optional(), | ||
| partNumber: zod.number().optional(), | ||
| partSize: zod.number().optional(), | ||
| url: zod.string(), | ||
| }), | ||
| ), | ||
| uploadId: zod.string().optional(), | ||
| }); |
There was a problem hiding this comment.
This schema is disconnected from the type we declared in scoreFileTypes. If one changes and the other doesn't, then we are validating the incorrect type.
The way to fix this is to move this schema into the scoreFileTypes.ts file, and then to use zod.infer to generate the type:
export const fileMetaDataSchema = zod.object({
objectId: zod.string(),
objectKey: zod.string().optional(),
objectMd5: zod.string().optional(),
objectSize: zod.number().optional(),
parts: zod.array(
zod.object({
md5: zod.string().nullable().optional(),
offset: zod.number().optional(),
partNumber: zod.number().optional(),
partSize: zod.number().optional(),
url: zod.string(),
}),
),
uploadId: zod.string().optional(),
});
export type FileMetaData = zod.infer<typeof fileMetaDataSchema>;
ciaranschutte
left a comment
There was a problem hiding this comment.
looking really good overall - couple of q's , couple of style fix ups
| }): Promise<{ fileUrl: string; fileName?: string; indexFileUrl?: string }> => { | ||
| const { documentId } = esConfig; | ||
| const elasticDocument = searchResult._source; | ||
| if (elasticDocument.file_type && !BamFileExtensions.includes(elasticDocument.file_type)) { |
There was a problem hiding this comment.
simplify to !BamFileExtensions.includes(elasticDocument.file_type) ?
There was a problem hiding this comment.
This is for TS b/c BamFileExtensions does not include undefined
| const authKey = process.env.ES_AUTH_KEY; | ||
| const esHost = process.env.ES_HOST_URL; | ||
| if (!(authKey && esHost)) throw new Error('Required .env configuration values are missing'); | ||
| if (!(authKey && esHost)) throw new Error('Required ElasticSearch .env configuration values are missing'); |
There was a problem hiding this comment.
wrap the "if"
good giving a better message - maybe we should go all the way and say no ES_AUTH_KEY or ES_HOST_URL?
There was a problem hiding this comment.
Right -- added several wrapping {} brackets and improved error messages
| export const infoLabelPercentCopy: { [P in BamPercentKey]: string } = { | ||
| mapped_reads: |
There was a problem hiding this comment.
this is the current usage in a consumer, example from Stage:
<IobioPanel>
<IobioLabelInfoButton label={displayNames[key]}>
<div slot="content">
<p>{infoLabelPercentCopy[key]}</p>
</div>
</IobioLabelInfoButton>
<IobioPercentBox percentKey={key} totalKey="total_reads" />
</IobioPanel>There was a problem hiding this comment.
None of these are really "default descriptions" because the consumer eg. Stage is selecting copy based on the key. There's some "library thinking" to be applied here and I'm not 100% clear what the end goal is.
if these are truly library level defaults, should they display when not given input from a consumer?
There was a problem hiding this comment.
OK so some background info to provide here. iobio-charts exports the Label and InfoButton tooltip together as one component. The content is for the pop up modal. We don't have our own copy for the modal (I'm using what is on Iobio's site).
But the consumer might. So making these a default (display when there's no content) on our package side is a smart suggestion.
There was a problem hiding this comment.
Restructured the info buttons to show standard display names and modal copy
This requires a bamKey string prop and overrides additional labels/children if provided
| export interface IobioDataBrokerProps extends IobioElementProps { | ||
| 'alignment-url': string; | ||
| 'index-url'?: string; | ||
| server?: string; | ||
| } |
There was a problem hiding this comment.
I think the props are camelCased ?
<IobioDataBroker alignmentUrl={fileUrl} indexUrl={indexFileUrl}...>
There was a problem hiding this comment.
react component props should be camelCased while html elements (and web components) are kebab-cased
There was a problem hiding this comment.
Shoot yeah there's some overlap here that's not correct, looking into it
There was a problem hiding this comment.
This file is for JSX to recognize the web components. I've updated the names and definitions to be a bit more reflective (hasn't been looked at it in depth for about a year). The kebob case is intentional because those are the properties of the web components.
|
|
||
| export default IobioPanel; | ||
|
|
||
| export type IobioPanelType = typeof IobioPanel; |
There was a problem hiding this comment.
What's the use case of this?
Is there a case where we want to provide a specific IobioPanel react node as a prop?
There was a problem hiding this comment.
I think these were intended to have a Type representation for the components. But they are unused here and in Stage so they could probably be removed.
There was a problem hiding this comment.
Naming conventions generally don't want a type to be named with Type, its redundant. There is no harm in having the type name be the same as the variable name (ie. IobioPanel).
There was a problem hiding this comment.
@joneubank I removed all of these IobioComponentType definitions, they don't have an immediate use case:
e689473
joneubank
left a comment
There was a problem hiding this comment.
Looks pretty good, left two very small suggestions.
|
|
||
| export type IobioInfoModalKeys = BamHistogramKey | BamPercentKey; | ||
|
|
||
| export const infoModalCopy: { [K in IobioInfoModalKeys]: string } = { |
There was a problem hiding this comment.
| export const infoModalCopy: { [K in IobioInfoModalKeys]: string } = { | |
| export const infoModalCopy: Record<IobioInfoModalKeys, string> = { |
| const urlParams = new URLSearchParams(scoreDownloadParams).toString(); | ||
| try { | ||
| const scoreUrl = urlJoin(scoreApiUrl, scoreApiDownloadPath, objectId, `?${urlParams}`); | ||
| const response = (await fetch(scoreUrl)).json(); |
There was a problem hiding this comment.
Combining .json() onto this line doesn't actually address the issue @ciaranschutte was pointing out, this now returns the Promise from the .json deserialization to the caller and requires them to handle those errors. If you want any errors from the .json call to be handled by the catch block in this function then you need to await the .json() call as well:
const response = await fetch(scoreUrl);
const jsonData = await response.json();
return jsonData;| uploadId: zod.string().optional(), | ||
| }); | ||
|
|
||
| export type FileMetaData = zod.infer<typeof fileMetaDataSchema>; |
#79 Feat: Changes to Support UI Changes in: https://github.com/overture-stack/stage/pull/253/files
Summary
#79 contains changes to fix the rendering of Iobio Labels
This requires an update to iobio-charts @0.26.0 and new JSX definitions
This PR bundles the library update with several other package improvements
Issues
Description of Changes
Readiness Checklist
.env.schemafile and documented in the README