How to bold a single element in Arcade label expression for FeatureLayer

142
6
08-09-2022 07:45 AM
LukeCalladine
New Contributor III

Hey all,

I'm trying to build out an Arcade expression to label my FeatureLayers as I've now reached a point where Y/X offset no longer works due to the dynamic-ness of the data being entered.

This is my current expression: 

`"<BOL>" + $feature.a4title + "</BOL>" + TextFormatting.NewLine + $feature.a4context`

It renders correctly in ArcGIS Pro but renders like this in my mapping application:

LukeCalladine_0-1660056094476.png

I've tried switching out to the standard <b> HTML variant but still no luck.

Is it just not possible to bold a single Arcade field in the JavaScript API 4.X yet?

Cheers,

Luke

0 Kudos
6 Replies
KristianEkenes
Esri Regular Contributor

That's correct. This isn't supported in the JS API, and I don't think it's on the roadmap either. You could try separating out the bolded line as a separate label class. That's the only work around I can think of.

LukeCalladine
New Contributor III

Hey Kristian,

I think that's how I currently have it set up - two label classes with a Y-offset.

However, as the Content label class size increases it expands from the middle - which once it gets to a certain threshold, starts overlapping the Title label class. If I increase the Y-offset to accommodate on the larger labels - I end up with unsightly gaps on the smaller labels.

I'm thinking could I make the Y-offset dynamic, but that would require being able to access each label on creation to query its parent feature and check for size, which I'm fairly sure isn't possible...

Ah well, thanks for the help!

0 Kudos
KristianEkenes
Esri Regular Contributor

Yeah. Understood that the current workflow is a bit awkward. I'll pass this along to the labeling engine folks and see what they say.

0 Kudos
LukeCalladine
New Contributor III

Hey @KristianEkenes,

I've been trying to work out a way of getting around it and I've noticed a peculiar inconsistency - it may be intentional but thought I'd ask anyway.

The expression I posted above DOES produce a bold result when used within MapImageLayer as can be seen below, does MapImageLayer implement the arcade/HTML expression differently?

LukeCalladine_0-1660571182904.png

My work around now involves a MapImageLayer of a FeatureLayer - where I make the edits on the FeatureLayer and let the live edits generate labels in the MapImageLayer with a forced refresh on edit completion to display them.

P.s. On a side note - why do all the labels in the Basemaps plot over the top of created labels? Is there a way to stop that from happening?

0 Kudos
KristianEkenes
Esri Regular Contributor

Hi @LukeCalladine,

The difference between FeatureLayer labeling and MapImageLayer labeling is that FeatureLayer labels render client-side, whereas MapImageLayer labels render server-side. The JS API rendering engine is used for all client-side visualizations. MapImageLayer doesn't rely on that rendering engine. Rather, it renders using the same rendering engine you would see in Pro/Enterprise. So that explains how the labels will look the same on MapImageLayer in the web as they do in Pro. The rendering happens on the server and the client requests an image of that rendering, which is then overlaid on the map view.

Regarding basemap labels. They likely come from a layer in the Basemap.referenceLayers If you move that layer representing basemap labels from the basemap to the Map.layers, then it will render in the order of the Map.layers. Here's an example of how you can move the label layer to the map operational layer so the labels render below the feature layer: https://codepen.io/kekenes/pen/dymgxgw?editors=100 

0 Kudos
LukeCalladine
New Contributor III

Thanks for the explanation @KristianEkenes, I had an inkling it was maybe server-side but had zero confidence in my assumption!

Thanks also for the CodePen example - that has indeed fixed my issue, although I will now need to work out some sort of clean-up as it keeps labels in place when using the BaseMaps widget!

Again, appreciate the help!

0 Kudos