POST
|
First I notice in the snippet above you have `facet=`, but the property is `facets` But even after you fix that, I think you'll still have a problem b/c you are trying to pass the facets as an attribute. For non-scalar properties (i.e. objects and arrays), the way to set them on custom elements is render the element w/o specifying any attribute value for that property, and then use JS after the element has rendered like: const el = document.querySelector('arcgis-hub-content-gallery')
el.facets = facets
... View more
05-05-2022
07:32 AM
|
0
|
0
|
232
|
IDEA
|
@sccwrp This should be fixed now. FYI - you may want to lock the URLs to point to a specific beta release. See the new "About beta" section of the docs.
... View more
04-20-2022
02:36 PM
|
0
|
0
|
1033
|
IDEA
|
Thank you @sccwrp. The repository is not down, however, it is not yet public. However, you can still learn about and use the components from the documentation: https://esri.github.io/hub-components/ which includes a getting started guide that shows how to install the components from NPM, or load them from the CDN. There's also a page for each component with a live example of how to use it. Some caveats. Currently most of the guides are more oriented toward the Hub team members that are authoring the components. Some components will make more sense for external use (i.e. the come w/ "batteries included") than others, and the docs don't yet do a good job of differentiating them. I'll be working on those issues between now and UC 2022. Your feedback is welcome.
... View more
04-14-2022
08:41 AM
|
0
|
0
|
1105
|
POST
|
Thank you. I see the problem. I will respond here when we have it fixed.
... View more
05-26-2021
08:18 AM
|
0
|
2
|
1213
|
POST
|
Thank you for reporting this @Daniel_Hardwick. I'm sorry you're having this problem. Are you able to provide a link to a CSV dataset that doesn't work?
... View more
05-26-2021
08:03 AM
|
0
|
1
|
1217
|
POST
|
Download is available for items of type “Image Service”. If you visit any of these you will see a download drop down on the right side of the page below the map: https://hub.arcgis.com/search?type=image%20service Download is not available for raster layers of a map service.
... View more
04-27-2021
04:17 PM
|
0
|
2
|
1085
|
BLOG
|
FYI - as of 2/17/21, ArcGIS Hub no longer supports Internet Explorer. See this blog post for more information.
... View more
02-19-2021
12:52 PM
|
0
|
0
|
758
|
POST
|
> I have also noticed that layers which show this message miss the "rows" attribute, Search results w/o "rows" have not been indexed by our back end. There can be 2 reasons. Either they are not shared w/ everyone, and therefore not accessible to our indexer, or our indexer has not yet got around to indexing them yet > I found out that it helps to share and unshare the AGOL item with Open Data group couple of times After doing that, did you notice that the "rows" are visible in the search result? If so that means that the item (for the service) was indexed. > I am not so glad in this unpredictable behavior. You should not need to repeatedly share/unshare the items. Our indexers will find them as long as they are shared w/ everyone, and especially if they've been added to an Open Data group. It may take time. You may also find this useful: https://community.esri.com/community/gis/web-gis/arcgis-hub/blog/2019/12/09/how-to-manually-refresh-your-sites-content I can tell from the image above that the particular layer was indexed Regardless, even if you do not see a "rows" count on the search result (i.e. it has not been indexed or is not shared w/ everyone), you should still see the features on the map under most circumstances. We have a fairly complex set of rules that determines when to show or not show features, but generally speaking, you should never see that message for a layer w/ only 4 rows. The next time you have that happen, I'd be curious to know if there are any errors in the browser's console and or failed network requests.
... View more
01-24-2020
01:35 PM
|
1
|
1
|
1197
|
POST
|
Jonathan Moulding - Do you have a link to the web map with the clustered layer? How did you "change it to show clusters"? In the ArcGIS Online Map Viewer?
... View more
09-17-2019
07:38 AM
|
0
|
0
|
361
|
POST
|
FWIW, I've opened an issue to be able to do this w/o `overrides`: definition should provide a way to specify or override default axis labels · Issue #464 · Esri/cedar · GitHub
... View more
03-14-2019
09:00 AM
|
2
|
0
|
1681
|
BLOG
|
I agree that the new plugin is harder to configure than the above solution, but once you do get it working, at least you have the option of being able to achieve acceptable load performance on mobile. Here's more information on that: https://community.esri.com/people/TWayson-esristaff/blog/2018/05/10/arcgiswebpack-plugin-vs-esri-loader
... View more
05-10-2018
03:24 PM
|
0
|
0
|
1995
|
BLOG
|
This post is aimed at helping you decide when to use the new @arcgis/webpack-plugin or esri-loader in applications built with webpack. I've recently had the opportunity to put the new webpack plugin through it's paces, and I came away with the impression that Rene Rubalcava, Yann Cabon, and the team have taken an important step forward in making the ArcGIS API for JavaScript more interoperable with other JavaScript frameworks and build tools. TLDR: Scroll down to see the Conclusion. Rumors of esri-loader's demise have been greatly exaggerated So you may be wondering why would you ever want to use esri-loader now that we have the plugin? First, if you're not using at least v4.7 of the ArcGIS API for JavaScript, you can stop reading this and head right on over to the esri-loader documentation. It also goes without saying that if you're using another module bundler besides webpack (such as rollup.js or parcel) that the webpack plugin won't be able to help you and that you'll need esri-loader instead. If you're developing Ember.js applications, which use Broccoli.js instead of webpack, head on over to ember-esri-loader. Functional parity? Very close... Still here? Great! Before getting into the details, I should start by identifying the ArcGIS API + webpack scenarios for which there was previously no other workable solution besides esri-loader. These scenarios are listed from more common to more advanced: You do not have access to the weback configuration (i.e. you were using a framework's CLI tool) You want to lazy-load the ArcGIS API after the rest of the application was loaded and rendered You want to use the ArcGIS API in a server-side rendered (SSR) application Handles the hard stuff well I'm happy to report that the new webpack plugin handles the more advanced scenarios (lazy-loading and use in a SSR application) very well! For each of the plugin's two demo applications I was able to make a branch that demonstrates how to lazy-load the esri bundles using dynamic import(). Here are the relevant TypeScript and Babel commits. I also able to confirm that each of those branches had roughly the same initial load performance as their esri-loader equivalents. Importantly, using lazy-loading (with either the webpack plugin or esri-loader) resulted in a 4x decrease in the time it took to see anything other than a blank white screen. Stephen Sylvia expanded on that idea by creating a lightning fast (loads on a mobile phone on 3G in under 2 seconds) prototype that uses placeholder images for maps until the user wants to interact with them. Finally, I riffed on his work and created a branch that uses server-side rendering to demonstrate how you could optimize such a site for SEO. It would be easy to add a commit to that branch that leverages sever-side rendered Open Graph meta tags for rich social media sharing. Some work to be done However, these are still early days for the webpack plugin, and there are a few kinks to be worked out so that you can just use it in any webpack project. Specifically, at a bare minimum you need to be able to add it to the webpack config's array of plugins. The CLIs are getting better these days about letting you have access to the webpack config, but worst case scenario you may need to "eject" from the CLI in order to do so. You may find that even once you are able to add the plugin to your webpack config, some of it's settings conflict with those of other plugins added by the CLI. I had this problem when trying to add the webpack plugin to a create-react-app application. I poked and prodded a bit, and was able to resolve certain issues, but others were beyond my webpack fu (which isn't saying much). Coming soon... All in all though, I am confident that these incompatibilities will be worked out soon, and we'll have functional parity between the webpack plugin and esri-loader. If you're using the ArcGIS API with angular-cli, vue-cli, create-react-app, etc I hope you'll jump into the fray and try to help us figure out how to resolve these types of issues. So, which should I use? Let's say you've rolled your own webpack config (rather than starting from a CLI) and you can use either the webpack plugin or esri-loader in your app today. Why would you choose one or the other? Generally, I'd say that esri-loader makes it easier to integrate the ArcGIS API into a webpack application, because there is zero configuration. However it forces you into using complicated async patterns when working with 'esri' modules. In contrast, I'd say that the webpack plugin may be a bit more complicated to set up and configure, but once you do it offers more flexibility. Also, the webpack plugin does result in increased build times, but they're working on that, but coming from the ember-cli, I barely noticed. import and import() The biggest difference is that only the webpack plugin allows you to use import statements for esri modules. Instead esri-loader's asynchronous loadModules() API forces developers to consider the cost of loading esri modules and to use strategies that defer that cost by consolidating their use. This works well in applications that make very simple use of the ArcGIS API, such as a single map component. However this can become cumbersome in an application that has multiple components that work with the ArcGIS API such as a map component, a legend component, and a drawing toolbar, etc. Those types of applications will be easier to develop using the webpack plugin and import statements. However, if you want to lazy-load the ArcGIS API and it's modules (and if you're targeting mobile you should), you won't be able to freely use import statements anyway. Instead you'll end up grouping them into one or a few modules that you lazy-load with dynamic import() and you'll probably end up creating your own internal async API that looks a lot like that of esri-loader! Hopefully someday we'll be able to just use import statements for esri modules w/o either of these libraries and have support for things like tree-shaking of the ArcGIS API modules. To that end, the webpack plugin is more future-proof than esri-loader. Conclusion Here's a side-by-side comparison of the high level capabilities. Capability esri-loader @arcgis/webpack-plugin Works with ArcGIS API < v4.7 Yes No Works with other bundlers besides webpack Yes No "Just works" with any framework CLI or webpack plugin Yes Not yet Can lazy-load the ArcGIS API and it's modules Yes Yes Can be used in a server-side rendered application Yes Yes Can import esri modules No Yes Is future-proof No Yes When you look at that list, it becomes clear that that esri-loader is the versatile, backwards-compatible fallback solution, and @arcgis/webpack-plugin is a forward-looking link toward a brighter future. If you are able to give the plugin a try in your application I recommend that you do. If not, or if it doesn't work out for you, esri-loader will always be here for you.
... View more
05-10-2018
01:20 PM
|
2
|
0
|
3750
|
Title | Kudos | Posted |
---|---|---|
1 | 08-24-2016 10:39 AM | |
1 | 04-21-2016 11:22 AM | |
1 | 05-14-2015 09:58 AM | |
1 | 12-13-2016 12:55 PM | |
1 | 12-01-2016 10:20 PM |
Online Status |
Offline
|
Date Last Visited |
05-05-2022
11:44 AM
|