Hi all, we have created a web app based on custom builds, using webpack. We are managing the assets of JavaScript API (4.24.7) by copying the locally and setting the value of esriConfig.assetsPath to the right path. Everything works perfectly! We have decided to start integrating Calcite Design system (1.0.0-beta.92) to our web app. So far great experience! We are also managing the assets of Calcite locally. So we copy them to a location and then we use the function setAssetsPath to define the path. Everything works fine too (almost 😉 )! The JS API is using Calcite assets (1.0.0-beta.82 for the version we use). They exist in the folder node_modules\@arcgis\core\assets\components\assets. Everything works fine overall but we noticed the following: * All the calcite design components are using the assets from the JS API path and not from the setAssetsPath. Either the setAssetsPath doesn't work properly or there is a conflict between setting assetsPath for JS API and for calcite design? Again, everything works, but we are using different versions of assets. It might become an issue in the future? * Since JS API is using calcite components, the css of the JS API includes already calcite styles. Eventually we are loading them twice (and from different versions), one css from calcite and once css from JS API. It makes sense, but I wonder if there is a more optimal way to do this. So the question would be: Are there any best practices of integrating Calcite Design with JS API with custom builds? There are very nice examples in github for Calcite Design and nice examples for JS API but I could not find any example with both of them together 😀

nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Building Apps with Calcite design and JS API (accessing assets, css...)

MichailMarinakis1

Hi all,

we have created a web app based on custom builds, using webpack. We are managing the assets of JavaScript API (4.24.7) by copying the locally and setting the value of esriConfig.assetsPath to the right path. Everything works perfectly!

We have decided to start integrating Calcite Design system (1.0.0-beta.92) to our web app. So far great experience! We are also managing the assets of Calcite locally. So we copy them to a location and then we use the function setAssetsPath to define the path. Everything works fine too (almost 😉 )!

The JS API is using Calcite assets (1.0.0-beta.82 for the version we use). They exist in the folder node_modules\@arcgis\core\assets\components\assets.

Everything works fine overall but we noticed the following:

All the calcite design components are using the assets from the JS API path and not from the setAssetsPath. Either the setAssetsPath doesn't work properly or there is a conflict between setting assetsPath for JS API and for calcite design? Again, everything works, but we are using different versions of assets. It might become an issue in the future?
Since JS API is using calcite components, the css of the JS API includes already calcite styles. Eventually we are loading them twice (and from different versions), one css from calcite and once css from JS API. It makes sense, but I wonder if there is a more optimal way to do this.

So the question would be: Are there any best practices of integrating Calcite Design with JS API with custom builds?

There are very nice examples in github for Calcite Design and nice examples for JS API but I could not find any example with both of them together 😀

Trouver plus de publications taguées avec

Accepted answers

AndyGup

> It seems like the setAssets() function, somehow, is not honored.

Try copying all of your assets to a common directory . There is a known issue when there are multiple calcite components being used with the JS API. It has do with calcite-components using Stencil.js and Stencil also uses setAssetsPath => https://stenciljs.com/docs/assets#setassetpath.

All comments

MichailMarinakis1

Great! I will try that. I will copy the assets to a common folder and take it from there.

Thanks again for the replies!

MichailMarinakis1

Thank you for the clarification! Good news that there is no overlap between the two css packages.

We will try to align the calcite version on our project with the version delivered with JS API.

At the repository above, I created an example of local assets and the use of both css packages. It works fine, except of the local assets. The end user doesn't see any difference. If we use the same version as the one shipped with JS API, then we have a workaround. But the issue of referencing assets from JS API instead of calcite assets remains in the code example above, even when we use properly the setAssets() from calcite library. It seems like the setAssets() function, somehow, is not honored.

AndyGup

Hi @MichailMarinakis1 correct there is no overlap between the JS API CSS and calcite-components CSS. Here is an SDK sample app showing them being used in the same application: https://developers.arcgis.com/javascript/latest/sample-code/sandbox/?sample=watch-for-changes-reactiveutils.

Only as long as Calcite is in beta, you will need to ensure you are using the right version for the corresponding JS API release, and that information can be found in the JS API release notes under the Additional Packages section, for example: https://developers.arcgis.com/javascript/latest/release-notes/#additional-packages

Were you able to get a prototype working that combined the two css packages?

MichailMarinakis1

Hi Andy,

thank you for your reply! Please find here a repo where the issue is reproduced:

https://github.com/MichalisM/esri-jsapi-resources/tree/master/esm-samples/jsapi-custom-widget

I have forked the original project and added our configuration of webpack. I also integrated some calcite components in the custom widget example.

As described on the initial post, we manage locally the assets with webpack and we copy them in different directories (.core/assets and .calcite/assets). When we use calcite components, either rendered with a custom widget or directly create them in the window.document, then they use the assets from .core/assets instead of .calcite/assets. Both directories are available on the server.

Small question: There is no overlap between the following css?

import "@arcgis/core/assets/esri/themes/light/main.css";

and

import "@esri/calcite-components/dist/calcite/calcite.css";

We are not intentionally mixing calcite versions. ArcGIS JS API is shipped with a different version than the calcite design that we use. Are you proposing that we should always use the same calcite design version as the one included in the JS API release?

Thank you again!

AndyGup

Hi @MichailMarinakis1 can you share a simple github repository that reproduces the issue? Also, since Calcite is still in beta, we don't recommend mixing different versions of Calcite. The prerelease tags cause issues with the dependency trees.

And, yes, thanks for the feedback on needing some doc or an example. We are working on getting that addressed.

Rejoindre la conversation

Les membres connectés peuvent publier, suivre les mises à jour, et plus encore. Nouveau ici ? Inscrivez-vous gratuitement.

Liens rapides

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.