Forem: Mohsen Mirshahreza

Dynamic React: Rendering Remote JSX without a Build Step

Mohsen Mirshahreza — Tue, 18 Nov 2025 22:03:51 +0000

Dynamic React: Rendering Remote JSX without a Build Step

Introduction

Modern React development is often synonymous with complex build pipelines involving Webpack, Vite, or Rollup. While these tools offer optimization, they introduce a significant barrier to entry and rigidity. This project, ReactDynaCodeDynaHtml, demonstrates a powerful alternative: loading, compiling, and rendering React components dynamically in the browser at runtime.

Core Techniques

1. In-Browser Compilation with Babel Standalone

Instead of pre-compiling JSX, this project utilizes babel.min.js (Babel Standalone). This library runs entirely in the browser, transforming JSX syntax into standard JavaScript that the browser can execute on the fly.

2. Dynamic Fetching

The application uses the standard fetch API to retrieve component code (stored in .html or .js files) as plain text strings. This allows components to be stored remotely or locally and loaded only when needed.

3. Scoped Execution via `new Function`

The heart of the system is the DynamicContent loader. Once the code is fetched and transformed by Babel, it is executed using the new Function constructor.

const func = new Function('React', ...contextKeys, funcBody);

This technique allows us to:

Inject dependencies (like React) explicitly.
Pass props and context variables dynamically.
Isolate the component's scope to prevent global namespace pollution.

Advantages

Zero Build Configuration: No npm run build, no node_modules hell, and no complex config files.
Hot-Swappable Architecture: You can update a component file on the server, and clients will see the change immediately upon refresh without redeploying the entire application.
Runtime Flexibility: Ideal for CMS-like structures where layout or logic needs to be defined by the backend or changed frequently.
Rapid Prototyping: Excellent for quick experiments or adding React to legacy applications without a full rewrite.

How to Use

Setup: Ensure index.html includes React, ReactDOM, and Babel Standalone.
The Loader: Use the DynamicContent component to load external files.

   <DynamicContent url="./my-component.js" context={{ user: 'Alice' }} />

Component Files: Write standard React functional components in your external files. They should return the JSX element directly.

Conclusion

While not a replacement for build steps in massive, performance-critical applications, this "No-Build" approach offers unmatched flexibility for dynamic content, plugin systems, and lightweight integrations.

Source Code
You can find the complete source code for this project on GitHub: https://github.com/mirshahreza/ReactDynaCodeDynaHtml

Geographic in Zync: PostGIS-Inspired Spatial Utilities for SQL Server

Mohsen Mirshahreza — Wed, 29 Oct 2025 04:42:01 +0000

Geographic in Zync: PostGIS-Inspired Spatial Utilities for SQL Server

Zync is a lightweight, Git-powered package manager for SQL Server that turns collections of SQL scripts into installable, dependency-aware packages. It helps teams ship consistent, reusable database utilities with simple, discoverable commands.

This article focuses on the Geographic package and how it intentionally mirrors PostGIS patterns from PostgreSQL—so spatial developers can feel at home while working on Microsoft SQL Server.

GitHub: https://github.com/mirshahreza/Zync
Geographic package folder: MsSql/Packages/Geographic

Why PostGIS patterns?

PostGIS is the de facto standard for spatial data processing in PostgreSQL. Its thoughtful API design, consistent naming (ST_*), and rich function set have shaped how many engineers think about geospatial work.

The Zync Geographic package adopts the same mental model and naming conventions so that:

Function names and semantics are familiar to PostGIS users.
Common tasks (constructing geometry, spatial relationships, buffering, distance queries) look and feel similar.
Migration between PostgreSQL/PostGIS and SQL Server is easier for mixed environments.

Under the hood, these functions are implemented using SQL Server's native spatial types (geometry and geography) and T‑SQL, and they expose a PostGIS-like surface area where possible.

Design highlights

ST_* naming: All spatial helpers follow the ST_* convention with a protective Zz prefix, e.g., ZzST_Buffer, ZzST_Contains, ZzST_DWithin.
Geometry-first: Core ST_* functions operate on SQL Server geometry; where geodetic accuracy is needed, separate helpers use latitude/longitude and the Haversine formula.
WKT/WKB friendly: Constructors and I/O helpers accept and return WKT/WKB, easing copy/paste and testing.
SRID defaults: SRID 4326 (WGS 84) is the default when an SRID is not explicitly provided.
Familiar semantics: Names and behavior are intentionally aligned with the PostGIS reference where supported by SQL Server's spatial stack.

See the quick reference: MsSql/Doc/POSTGIS_FUNCTIONALITIES.md

What’s included

Beyond utility routines like coordinate validation and distance conversions, the package ships 45+ PostGIS‑style functions (ZzST_*) including:

Geometry constructors: ZzST_Point, ZzST_MakePoint, ZzST_MakeLine, ZzST_MakePolygon, ZzST_MakeEnvelope
I/O helpers: ZzST_AsText, ZzST_AsBinary, ZzST_GeomFromText, ZzST_GeomFromWKB
Accessors: ZzST_X, ZzST_Y, ZzST_GeometryType, ZzST_SRID
Measurements and predicates: ZzST_Distance, ZzST_Length, ZzST_Area, ZzST_Perimeter, ZzST_Contains, ZzST_Within, ZzST_Intersects, ZzST_DWithin
Processing: ZzST_Buffer, ZzST_Centroid, ZzST_Envelope, ZzST_ConvexHull, ZzST_PointOnSurface
Set operations: ZzST_Union, ZzST_Intersection, ZzST_Difference, ZzST_SymDifference

You’ll also find pragmatic helpers commonly needed in app backends:

ZzIsPointInRadius, ZzGetPointsInRadius, ZzGetBoundingBox, ZzGetNearestPoint
Converters and formatters: ZzConvertDMSToDecimal, ZzConvertDecimalToDMS, ZzConvertDistance/Area/Speed

Browse the full list and examples in MsSql/Packages/Geographic/README.md

Usage examples

Note: geometry is used below; replace with geography where your use case requires spheroid-aware measurements. Default SRID is 4326 unless specified.

1) Construct points and lines (PostGIS‑like):

-- POINT(lon lat)
SELECT [dbo].[ZzST_AsText](
  [dbo].[ZzST_MakePoint](51.3890, 35.6892, NULL, NULL)
) AS WKT;

-- LINESTRING from two points
SELECT [dbo].[ZzST_AsText](
  [dbo].[ZzST_MakeLine]('51.3890,35.6892;51.4000,35.7000', 4326)
) AS WKT;

2) Spatial relationships and predicates:

-- Envelope (bbox) that contains a point
DECLARE @bbox geometry = [dbo].[ZzST_MakeEnvelope](51.3800, 35.6800, 51.4200, 35.7200, 4326);
DECLARE @pt   geometry = [dbo].[ZzST_GeomFromText]('POINT(51.3890 35.6892)', 4326);
SELECT [dbo].[ZzST_Contains](@bbox, @pt) AS ContainsPoint; -- 1 = true, 0 = false

3) Distance and proximity:

-- Are two points within 1km?
DECLARE @a geometry = [dbo].[ZzST_GeomFromText]('POINT(51.3890 35.6892)', 4326);
DECLARE @b geometry = [dbo].[ZzST_GeomFromText]('POINT(51.4000 35.7000)', 4326);
SELECT [dbo].[ZzST_DWithin](@a, @b, 1000.0) AS IsNearby;

4) Buffering:

-- Create a small buffer around a point (~units depend on SRID)
DECLARE @pt geometry = [dbo].[ZzST_GeomFromText]('POINT(51.3890 35.6892)', 4326);
SELECT [dbo].[ZzST_AsText]([dbo].[ZzST_Buffer](@pt, 0.01)) AS Buffered;

5) “App friendly” helpers with lat/lon inputs:

-- Check if a point (lat/lon) is within a radius (KM/MILE/M)
SELECT [dbo].[ZzIsPointInRadius](35.6892, 51.3890, 35.7000, 51.4000, 10, 'KM') AS InRadius;

-- Find points within a radius around a center point (example table schema assumed)
-- SELECT * FROM [dbo].[ZzGetPointsInRadius](
--   @centerLat, @centerLon, @radiusValue, @radiusUnit, @YourPointsTable
-- );

Mapping for PostGIS users

ST_* naming is preserved with a Zz prefix: e.g., PostGIS ST_Buffer ≈ ZzST_Buffer.
WKT/WKB inputs are supported via ZzST_GeomFromText and ZzST_GeomFromWKB.
SRID management via ZzST_SRID and ZzST_SetSRID (no transform).
SQL Server equivalents (internal) may differ in name (e.g., STBuffer, STDistance), but the wrapper functions provide PostGIS‑like ergonomics.

Quick mapping table

PostGIS	Zync Geographic	Notes/Differences
ST_Buffer	ZzST_Buffer	Buffers on geometry; units depend on the SRID.
ST_DWithin	ZzST_DWithin	Proximity within a distance (units = coordinate system units). Consider geography for geodetic accuracy over long distances.
ST_Intersects	ZzST_Intersects	Returns 0/1; works across geometry types.
ST_Contains	ZzST_Contains	Tests if A completely contains B.
ST_Within	ZzST_Within	Tests if A is within B.
ST_Distance	ZzST_Distance	Minimum 2D distance; for lat/lon geodetic cases use ZzCalculateDistance (Haversine).
ST_AsText	ZzST_AsText	WKT output for viewing/debugging.
ST_GeomFromText	ZzST_GeomFromText	Construct geometry from WKT with SRID.

Caveats and tips:

Be explicit about SRIDs when mixing data from multiple sources.
Geography vs geometry: choose geography for long‑distance geodetic calculations; use geometry for planar operations and most predicates.
Tolerance and units: buffer radii and distances depend on the coordinate system—prefer consistent SRIDs (WGS 84 for GPS).

Installation

Install directly from the Zync repository using the Zync command:

-- Install the entire Geographic package
EXEC [dbo].[Zync] 'i Geographic';

-- Or install only spatial functions
EXEC [dbo].[Zync] 'i Geographic/ZzST_*.sql';

If you don't have Zync yet, run MsSql/Zync.sql from the repository to bootstrap the core procedure. See MsSql/Doc/ARTICLE_EN.md for a gentle introduction and MsSql/scripts/README.md for automation.

References

Zync repository: https://github.com/mirshahreza/Zync
PostGIS docs: https://postgis.net/docs/
SQL Server spatial types: geometry and geography

If you’ve been productive with PostGIS, you’ll feel right at home: the Zync Geographic package brings a familiar, modern spatial toolbox to SQL Server—tested, documented, and ready for production.

Stop Juggling SQL Scripts: Introducing Zync, the Database Package Manager

Mohsen Mirshahreza — Fri, 26 Sep 2025 21:24:36 +0000

If you’ve ever worked on a large database project, you know the pain. You have folders filled with SQL scripts for stored procedures, functions, and views. Script A depends on B, which depends on C. Deploying to a new environment means running them in the correct order, and heaven forbid you miss one. Sharing reusable utilities across projects is a copy-paste nightmare.

We’ve built powerful package managers for our application code—npm for Node.js, NuGet for .NET, Pip for Python. They handle dependencies, versioning, and distribution flawlessly. So why are we still managing database scripts like it’s 1999?

It’s time for a change. Introducing Zync, a simple but powerful package manager for SQL Server, designed to bring the convenience of modern package management directly into your database.

The Chaos of Manual Script Management

Before we dive into the solution, let’s appreciate the problem. Traditionally, managing a collection of database objects involves:

Manual Dependency Tracking: You have to remember that CreateUserView.sql must run after CreateUserTable.sql. This knowledge is often stored in a developer's head or a fragile README file.
Scattered Scripts: Utility functions and procedures are often scattered across different project folders, leading to code duplication and maintenance headaches.
Inconsistent Deployment: Deploying to a new database is often a manual, error-prone process that can easily lead to inconsistencies between development, staging, and production environments.
Difficult Collaboration: Sharing a set of useful database tools with your team or the community is far from straightforward.

Zync was born out of this frustration. It treats your database objects as what they are: packages—modular, reusable, and dependency-aware units of code.

How Zync Simplifies Your Workflow

Zync is built around a single stored procedure, dbo.Zync, that acts as your command-line interface inside SQL Server Management Studio (SSMS). Once installed, it gives you access to a world of functionality through simple commands.

The core philosophy is simple: host your SQL packages in a GitHub repository, and let Zync handle the rest.

Key Concepts:

📦 Package Management: Group related SQL objects (procedures, functions, etc.) into a "package," which is simply a folder in a repository.
🔄 Automatic Dependency Resolution: Define dependencies for a package, and Zync will automatically fetch and install them first.
🎯 Simple Commands: A clean, intuitive command structure for listing and installing packages.
🏗️ Standardized Repositories: Use the official Zync repository or point it to your own for private packages.

Getting Started with Zync

Ready to give it a try? It only takes a few minutes to get up and running.

Step 1: Install the Zync Stored Procedure

First, you need to install the core Zync procedure in your target database. Just download and run the Zync.sql script from the official repository. This one-time setup is all you need.

Step 2: List Available Packages

Once installed, you can see which packages are available in the default repository with the ls (list) command.

EXEC [dbo].[Zync] 'ls'

This command queries the GitHub API and returns a list of available packages (directories) you can install.

Expected Output:

Fetching available packages from repository...
Available packages:
-------------------
AppEnd
DbUtils
Number
String
-------------------

Step 3: Install Your First Package

Let's say you need a set of string manipulation utilities. You can install the String package with the i (install) command.

EXEC [dbo].[Zync] 'i String'

Here’s what happens behind the scenes:

Zync constructs the URL to the package's main SQL file in the repository.
It fetches the content of the script.
It checks for any dependencies listed at the top of the file and installs them first.
Finally, it executes the script, creating all the objects from the String package in your database.

Output:

Installing package: 'String'...
 -> Fetched 'String' successfully.
 -> Package 'String' installed successfully.

Just like that, you now have access to useful functions like ZzSplitString and ZzCountWord without ever leaving your query editor.

You can also install a single script from a package if you don't need the entire collection:

-- Installs only the ZzSplitString function
EXEC [dbo].[Zync] 'i String/ZzSplitString.sql'

A Glimpse into the Zync Ecosystem

The default repository already includes several useful packages to get you started:

DbUtils: A powerful suite of tools for database administration, including procedures to create/drop tables, manage columns, and analyze object dependencies.
String: A collection of functions for common string operations like splitting, trimming, and counting.
Number: Helper functions for formatting numbers and converting byte sizes (e.g., to KB, MB, GB).
AppEnd: A set of building blocks for applications, including user and role management.

The Future is Bright

Zync is just getting started. The vision is to create a rich ecosystem of reusable database components. The roadmap includes:

Support for other databases like PostgreSQL, MySQL, and Oracle.
Package versioning to manage different versions of a package.
An uninstall command to safely remove packages.

Join the Movement

Managing database code shouldn't be a chore. Zync offers a streamlined, modern approach that saves time and reduces errors. It empowers developers to build, share, and reuse database utilities with ease.

Check out the project on GitHub, give it a star, and try it out in your own projects. Contributions, feedback, and ideas are always welcome.

Find the project here: https://github.com/mirshahreza/Zync

Mohsen Mirshahreza

Forem: Mohsen Mirshahreza

Dynamic React: Rendering Remote JSX without a Build Step

Dynamic React: Rendering Remote JSX without a Build Step

Introduction

Core Techniques

1. In-Browser Compilation with Babel Standalone

2. Dynamic Fetching

3. Scoped Execution via new Function

Advantages

How to Use

Conclusion

Geographic in Zync: PostGIS-Inspired Spatial Utilities for SQL Server

Geographic in Zync: PostGIS-Inspired Spatial Utilities for SQL Server

Why PostGIS patterns?

Design highlights

What’s included

Usage examples

Mapping for PostGIS users

Quick mapping table

Installation

References

Stop Juggling SQL Scripts: Introducing Zync, the Database Package Manager

The Chaos of Manual Script Management

How Zync Simplifies Your Workflow

Key Concepts:

Getting Started with Zync

Step 1: Install the Zync Stored Procedure

Step 2: List Available Packages

Step 3: Install Your First Package

A Glimpse into the Zync Ecosystem

The Future is Bright

Join the Movement

3. Scoped Execution via `new Function`