Latest Contributions by DavidSolari

After beating my head against this wall for a while, I consistently get runtime import errors when I try to load something as simple as the basemap toggle widget from another version of the SDK. I'll leave this open just in case some brave soul ever figures this out, but I'll stick to making simpler widgets and maybe work myself up to a dead-simple bulk editing widget that uses the bundled SDK. Thanks again for all your help Jeff!

Enterprise 11.5 The multiple feature editing workflows from the newer SDKs. We have dozens of apps with the WAB batch editing widget that we'd have to panic-port when we move to 12.1 so I want to provide a workaround. The map component is just for testing if anything will render, the final product will wrap the editor widget/component. I figured I'd start with the component used in nearly every code sample, just to avoid editor-specific issues for the time being. The map component I'm trying to import is the standard map component from all the SDK demos. The item id I'm providing is from a sample so it's publicly available. I've never seen a demo where the map component's CSS must be overridden to display properly, and when I check devtools the computed width and height are "auto" which means it should fill my parent div if there's anything to render. Your linked post looks fantastic (I can't believe none of my Google searches pulled it up) and I'll try and get your example implemented on my end just to see if there's any build/env issues. I did notice it's pulling in the bundled SDK's widgets and components, have you tried anything that involves using another version of the SDK like I'll need to do?

I need to wrap an Editor widget from a newer release of the JavaScript SDK in a widget targeting an older version of Experience Builder so my org can migrate from Web Appbuilder to Experience Builder before we upgrade to Enterprise 12.1. Unfortunately, I'm at my wit's ends here, I can't even get a simple map component working in a widget! Attached is my current widget folder, run npm update to grab the dependencies and then combine it with Experience Builder Developer Edition 1.17. I've aliased the npm packages as @arcgis434/map-components, @arcgis434/core and @esri434/calcite-components to avoid grabbing the default packages, not sure if that works under ExB. The settings files are all copy-pasted from the built-in Editor widget just to get something working, the meat is in this minimal widget that tries to load a hardcoded map as a test: export default function EditWidget(props: AllWidgetProps<IMConfig>) { const [jmv, setJmv] = React.useState<JimuMapView>(null); const mapId = props.useMapWidgetIds?.[0]; const onActiveViewChange = (jmv: JimuMapView) => { setJmv(jmv) } return ( <div className="widget-editor-434" style={{height: "100%", width: "100%"}}> {mapId != undefined ? <JimuMapViewComponent useMapWidgetId={mapId} onActiveViewChange={onActiveViewChange} /> : <p>No map selected.</p>} {jmv != null ? <arcgis-map item-id="f2e9b762544945f390ca4ac3671cfa72"></arcgis-map> : <p>Map not loaded.</p>} </div> ) } On my end this renders the placeholder elements if a map isn't selected, but renders an empty map component otherwise. Am I missing something small? Am I barking up the wrong tree? Will trying to mix JavaScript SDK components like this even work??

This is an incredible amount of info, thank you so much! This should be more than enough for me to get started.

Right now I'm the sole widget dev on the team, but if it's not too onerous for one guy I'd like to have something that supports multiple devs on the same team for the future. What I can say for sure is it's not multi-team, if we need to integrate someone else's widget source into our collection I'm fine with dumping it into a monorepo.

I'm getting started with custom widget development and I want to make sure I'm handling my source data as best as possible: For a single organization, should I do a monorepo or one repository per widget? At what folder "level" do I create the repository? I assume for multi-repository workflows each widget folder is a repository but how high up should you go for a monorepo? The docs mention a "shared-code" directory that isn't compiled into a widget but can hold common code for all widgets. Is it a good idea to use that or to create standard node packages and load them as standard dependencies? Does this change depending on how you structure the repositories?

Making the current option a "Combined Layer & Legend" toggle and adding layer and legend as separate options seems like the cleanest way to do this. If the combined toggle is on then you get the current menu but if it isn't the new toggles determine what buttons appear. 100% backwards compatibility without impeding the new feature, everyone wins!

I can confirm queries have trailing whitespace normalized (not leading whitespace though, that's something) in Pro. I'd suggest making an Idea to get strict whitespace as an option in Pro and on published services, although long standing design decisions like this are rarely updated. In the meantime, you can brute force strict whitespace by tacking this on to the end of your queries: AND CHAR_LENGTH(my_field) = CHAR_LENGTH(TRIM(BOTH ' ' FROM my_field)) That's the functions for a file geodatabase, you may have to use different string length and string trim functions.

‎04-02-2026

You can do all of this in Python, but working in the Spatial Join tool should be more performant as your datasets grow. For each point FC you can join in both polygon FCs, then loop over the results table in a Search Cursor to build up a dictionary of TARGET_FID to Location & Zone, then plug the Object ID of each point into that dictionary during the Update Cursor. This is what my Spatial Join parameters roughly looked like: arcpy.analysis.SpatialJoin( target_features="PT1", join_features="PG1 JC1;PG2 JC2", out_feature_class=r"memory\PT1_SpatialJoin", join_operation="JOIN_ONE_TO_ONE", join_type="KEEP_ALL", field_mapping='location "location" true true false 255 Text 0 0,First,#,PG1,location,0,254;zone "zone" true true false 255 Text 0 0,First,#,PG2,zone,0,254', match_option="INTERSECT" )

‎04-02-2026

If you aren't tallying up CPU instructions, the answer to "which option is more performant" is always "the one that ran the fastest in testing." Build up a representative dataset, move it to a testing clone of your usual RDBMS setup, load that into a copy of Pro on a free machine and then run some tests. For each attribute rule you'll want to run a bulk update, measure the time it took, reset the state of the test data outside of this time measurement, then run that entire test multiple times so you can average out external performance concerns. Then you just use whatever wins! Like @VenkataKondepati mentioned, option 2 is tougher to maintain in the future, so if that wins I recommend leaving a big fat comment in the attribute rule that explains what's going on and also includes option 1 for reference. Some resources for building your test runs: Update Cursor (to change an attribute and trigger the rule) Editor (to ensure the updates are processed in the same edit session) time.perf_counter (call this before and after the edit session, then do after - before to get a value of elapsed time. Always use counters like this instead of standard datetime functions to measure performance as they're more accurate and are unaffected by world clock synchronization)

‎03-26-2026

I'm currently managing a project involving paths and sample holes, letting users snap their sample points to the path would greatly improve the presentation of the data without running costly backend snapping updates.

‎03-26-2026

If you don't mind a bit of python, a Search Cursor with the special SHAPE@WKT field token will return that for every feature you need.

‎03-26-2026

Given the limited colours on tap, maybe try sticking to the 1/5/8 shades to minimize the overall intensity, that way any clashing is minimized. If possible you can do the 1/5 shades, plus 1+5 diagonal stripe combos which you can use to "break up" the map a bit.

‎03-26-2026

If you're able to turn your process into a model or script tool, you can look at the Scheduled Tools documentation to get it running whenever you want. Pay attention to all the notes about licensing and keep an eye on your logs, it's easy for Pro to lose a license and grind your tasks to a halt.

‎03-12-2026

I did this with Make years ago and it worked well. For Power Automate I think you just combine Get data from feature layer with Create a record in a feature layer and you're set. You can also try the Survey123 connector with Get surveys if you're working with survey submissions.

Online Status	Online
Date Last Visited	3 hours ago

My Ideas

Latest Contributions by DavidSolari

Re: How to Wrap a Newer Widget/Component in an Older Framework

Re: How to Wrap a Newer Widget/Component in an Older Framework

How to Wrap a Newer Widget/Component in an Older Framework

Re: Custom Widget Version Control Best Practices

Re: Custom Widget Version Control Best Practices

Custom Widget Version Control Best Practices

Re: Standalone Legend in Map Widget

Re: SQL Query for string values with trailing space

Re: Writing polygon values to point feature class based on an intersection of geometry.

Re: Arcade Performance: FeatureSetByRelationshipName vs. FeatureSetByName

Re: Support snapping to line and polygon edges (segments)

Re: Get WKT Values for a Polygon

Re: Cartographic help! Have to use brand colors

Re: can an import be automated?

Re: Upon feature creation, use webhook to copy feature to different feature layer

Re: SQL Query for string values with trailing spac...

How Do I Move Graphics from a Map to a Layout?

Re: can an import be automated?

Re: Upon feature creation, use webhook to copy fea...

Re: versioning (long transactions- short transacti...

Experience Builder Custom Widgets