-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
Expose FileTypeIcons as HTML strings #15405
Expose FileTypeIcons as HTML strings #15405
Conversation
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit 78b40ff:
|
Perf AnalysisNo significant results to display. All results
|
Asset size changesSize Auditor did not detect a change in bundle size for any component! Baseline commit: 52f5d891a274c6ea84aa4bb14cd961c1b89b2cf0 (build) |
|
||
src = `${baseUrlSizeType}.png`; | ||
iconName = type + size + PNG_SUFFIX; | ||
fileTypeIcons[iconName] = <img src={src} alt="" />; |
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.
minor question. Does this alt do something? Looks like it doesn't play any role here.
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.
May be wrong, but I believe this is due to accessibility scanners which will warn when you have an image without considering the alt tag (even providing a blank one is considered "accessible")...
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.
Might not be a bad idea to populate this alt text with type + " icon"
~ the type is not always super descriptive but we try our best to make it so.
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.
That is a good suggestion! Will take that up as a separate PR. Thanks!
src = `${baseUrlSizeType}.svg`; | ||
iconName = type + size + SVG_SUFFIX; | ||
fileTypeIcons[iconName] = <img src={src} alt="" />; | ||
_fileTypeIconsAsString[iconName] = `<img src="${src}" alt="" />`; |
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.
Rather than defining this on every definition, why not just generate it on demand in the exported functiongetFileTypeIconAsHTMLString
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 icon map is quite large in memory so it would be nice if made on-demand rather than bloat the page more.
// } | ||
// } | ||
// } | ||
|
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.
Hi @dzearing @KevinTCoughlin
Please have a look at this iteration. I had to do some refactoring and export a couple of functions from getFileTypeIconProps
to be able to implement the function getFileTypeIconAsHTMLString
which is basically kind of a sister clone of getFileTypeIconProps
in that it accepts the same kind of object but rather than just returning the iconName, it returns the entire DOM element as a string.
The other option I had considered is this commented snippet; in which the consumer had to call getFileTypeIconProps
to get the iconName and then just pass the iconName to the getFileTypeIconAsHTMLString
function, but that IMO required some regEx parsing, and hence I avoided this approach.
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.
can you remove the commented code
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.
@dzearing , removed.
Now that we're publishing beta versions of 8.0 please also port this to the master branch once it merges. |
@KevinTCoughlin @dzearing please have a look whenever you get time. Thanks :) |
…upta/office-ui-fabric-react into arkgupta/fileTypeIconsHTML
change/@uifabric-file-type-icons-2020-10-07-21-27-44-arkgupta-fileTypeIconsHTML.json
Outdated
Show resolved
Hide resolved
…fileTypeIconsHTML.json
IFileTypeIconOptions, | ||
} from './getFileTypeIconProps'; | ||
|
||
export function getFileTypeIconAsHTMLString( |
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.
Can you please add a comment to this? Also the function is not being exported through the index file. And you will probably need to run yarn update-api
to update the api-extractor definition of the library.
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.
Added a comment and exported through the index file. I couldn't find an existing api.md or api-extractor.json file for this package. Should I add one?
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.
@dzearing gentle ping! :)
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 should add an API extractor config and API file for this package (same pattern as other packages).
@@ -5,8 +5,8 @@ import { FileTypeIconMap } from './FileTypeIconMap'; | |||
const PNG_SUFFIX = '_png'; | |||
const SVG_SUFFIX = '_svg'; | |||
|
|||
const DEFAULT_BASE_URL = 'https://spoprod-a.akamaihd.net/files/fabric-cdn-prod_20201008.001/assets/item-types/'; | |||
const ICON_SIZES: number[] = [16, 20, 24, 32, 40, 48, 64, 96]; | |||
export const DEFAULT_BASE_URL = 'https://spoprod-a.akamaihd.net/files/fabric-cdn-prod_20201008.001/assets/item-types/'; |
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.
A little confused why these are being exported.
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.
(and the icon_sizes)
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 importing both of these in my test file. Also I need the default url while emitting the HTML as string from the new API.
…upta/office-ui-fabric-react into arkgupta/fileTypeIconsHTML
I am going to sign off to unblock the scenario; however I do think longer term we need to split out a separate |
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.
Coming in late here (sorry) but a couple comments to potentially address in the future.
@@ -0,0 +1,8 @@ | |||
{ | |||
"type": "patch", |
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 future reference, changes adding new public APIs should be minor not patch.
IFileTypeIconOptions, | ||
} from './getFileTypeIconProps'; | ||
|
||
export function getFileTypeIconAsHTMLString( |
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 should add an API extractor config and API file for this package (same pattern as other packages).
🎉 Handy links: |
Pull request checklist
$ yarn change
Description of changes
Rather than exposing the src of the
img
elements, we can just clone the whole JSX element as a string. If in the future, the implementation changes from<img>
to something else, then the corresponding DOM element which will be used can again be stored as a string in the same dictionary, so that the consumer can continue to consume it seamlessly.Focus areas to test
(optional)