// the find
wayqteam/h3_core
H3 hexagonal geospatial indexing for Dart & Flutter — Uber H3 v4.5.0 bindings via dart:ffi (native) and h3-js (web). GIS, mapping, geofencing & spatial analytics. A geohash alternative.
Dart/Flutter bindings for Uber's H3 hexagonal geospatial indexing library, targeting both native (via dart:ffi compiling the C source directly) and web (via h3-js interop). Covers the full H3 v4.5.0 API — ~80 functions — with a unified Dart API across all six platforms. For Flutter devs building anything involving spatial queries, geofencing, or mapping at scale.
Compiles C natively via Build Hooks instead of shipping prebuilt binaries — correct approach that avoids the ABI mismatch hell that plagues most FFI packages. The dual-backend design (FFI on native, h3-js on web) with a single identical API is well-executed and genuinely useful for Flutter's cross-platform story. Test suite is split by domain (indexing, traversal, hierarchy, edges, regions) with both native and web HTML test entrypoints — suggests the author actually ran and verified both backends. Async wrappers on the heavy operations (polygonToCells, gridDisk, compactCells) are the right call for Flutter's single-threaded UI.
1 star, 0 forks — this is a brand-new package with zero community validation, so you're early-adopting with no safety net if it goes unmaintained. Web setup requires a manual script tag in index.html pointing at unpkg CDN, which breaks offline builds and is a footgun in any CI environment without network access. The web backend depends on h3-js being loaded as a global — that's fragile compared to a proper JS module import. No mention of isolate/compute usage for the async wrappers; if they're just async wrappers around synchronous FFI calls on the main isolate, heavy polygon fills will still jank the UI.