Skip to content
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

Issues setting up va-icon for use and replacement of old icons #2353

Closed
2 of 6 tasks
lee-delarm6 opened this issue Jan 2, 2024 · 2 comments · Fixed by department-of-veterans-affairs/component-library#1067
Assignees
Labels

Comments

@lee-delarm6
Copy link

lee-delarm6 commented Jan 2, 2024

Bug Report

  • I’ve searched for any related issues and avoided creating a duplicate issue.

What happened

This is on vets-website, I didn't see anyone else using va-icon so it appears we are the first to try it out!

We're trying to switch over some of our icons to the va-icon using this USWDS V3 system, but ran into some issues with the sprite sheet not loading. We usually run an instances of check-in only (and pre-check-in), so not sure if it wasn't fully ready yet, or if we're doing something wrong, or need to add it to our local build in order to actually get the icon working or what. We figured it was plug and play, but doesn't seem quite like that.
Something like this

<va-icon icon="phone" size={4} />

throws this:

GET http://localhost:3001/assets/sprite.svg net::ERR_ABORTED 404 (Not Found)

https://design.va.gov/storybook/?path=/docs/uswds-va-icon--default

What I expected to happen

VA phone icon to appear

Reproducing

  • Chrome browser

Steps to reproduce:

As per above

Urgency

How urgent is this request? Please select the approriate option below and/or provide details

  • This bug is blocking work currently in progress
  • This bug is affecting work currently in progress but we have a workaround
  • This bug is blocking work planned within the next few sprints
  • This bug is not blocking any work
  • Other

Details

@caw310
Copy link
Contributor

caw310 commented Jan 4, 2024

@nickjg231 nickjg231 self-assigned this Jan 18, 2024
@nickjg231
Copy link
Contributor

This ticket will need to carry-over into the next sprint.

Current Understanding:
The core issue revolves around dynamically loading SVG assets (contained within component-library's sprite.svg file) for our va-icon and va-pagination web-components. Initially, the issue seemed to be that the SVG file wasn't included in the bundle from component-library, so the web-components were trying to reference a file which didn't exist when imported into another project. The first goal was to include the file, which was successfully done. Despite the SVGs now being present in the component-library/dist/assets directory, they are not accessible at runtime, leading to 404 errors when the components attempt to reference these assets.

Some of the fixes and attempts I've made are as follows:
Component Library Updates:

  • Modified va-icon and va-pagination components to include assetsDirs in the @Component decorator, which helps when a component references an asset.

  • Imported the .svg file directly using the raw-loader plugin to circumvent dynamic loading issues.

  • Incorporated svg-url-loader in the webpack.config.js to address potential issues related to SVG file handling.

  • Added new patterns to CopyPlugin in Webpack configuration to ensure SVG assets are copied into the dist folder during the build.

  • Included the src/ folder in the core package's package.json files array to address rendering issues post-asset bundling.

  • In content-build, I attempted to add the sprite.svg file to the build to ensure that vets-website would have it available in the /img directory like some other SVG files, but I recognize this might not be an optimal solution due to the undesirable dependency it creates between component-library and content-build. Both repos should be independent of each other, but doing this would've forced them to work together when both are imported into another library.

  • In vets-website, experimented with various CopyPlugin configurations to reference component-library assets directly from node_modules, aiming for a more direct asset handling approach.

Next Steps:
A few engineers and I are continuing to explore alternative solutions and adjustments to our build and bundling processes to ensure SVG assets are correctly bundled, referenced, and accessible at runtime without causing inter-library dependencies or complex build setups.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
6 participants