@es-joy/jsoe

JavaScript Object Editor.

Editing and viewing of arbitrary JavaScript objects.

See a demo of this tool or a demo of an app using this tool.

There is also experimental support for creating advanced search widgets based on a zodexy schema.

Formats

Formats are a collection of allowed types.

Supported formats include:

• Schemas (using zodexy serialization of Zod)
• Structured Cloning (using typeson) (e.g., IndexedDB values)
• JSON
• IndexedDB keys

Fundamental types

These are generally atomic types which correlate to JavaScript language structures.

Supported types include:

• Array reference (for cyclic arrays)
• Array
• BigInt
• bigintObject
• Blob
• Boolean object
• Date
• DOMException,
• Error
• TypeError, RangeError, SyntaxError, ReferenceError, EvalError, URIError, AggregateError, InternalError
• File
• FileList
• Map
• Non-editable type (catch-all for not-yet-supported object types; allows for preexisting data to be passed on transparently)
• null
• Number object
• number
• Object reference (for cyclic objects)
• Object
• RegExp
• Set
• String object
• string
• undefined

There are also the following fundamental (structured-cloning capable Zodexy) schema types:

• boolean (using in place of true/false when schema specifies)
• nan (standalone in Zodexy)

And there are the following non-structured-cloning Zodexy schema types:

• function
• promise
• symbol

Has some support for JSON references, but no UI for them at preent.

Subtypes

These map to a subset of JavaScript language structures. Note that false and true were common and limited enough in number to justify their own subtype for the sake of having a quick pull-down entry.

Supported subtypes include:

• Blob (text/html)
• false
• true

Supertypes

These are collections of individual types, justified by the subitems not being so frequent as to necessitate their own separate enumeration.

Supported supertypes include:

• Special Real Number (Infinity, -Infinity, -0) - Used with IndexedDB keys (even though -0 apparently to be converted to 0)
• Special Number (Infinity, -Infinity, -0, NaN) - Used with Structured Cloning values
• DOMMatrix (also includes DOMMatrixReadOnly)
• DOMPoint (also includes DOMPointReadOnly)
• DOMRect (also includes DOMRectReadOnly)
• buffersource includes ArrayBuffer, DataView, and TypedArrays (int8array, uint8array, uint8clampedarray, int16array, uint16array, int32array, uint32array, float32array, float64array, bigint64array, biguint64array)

Search widgets

Alongside viewUI/editUI (rendering controls for a value), jsoe can also build a search widget from a zodexy schema alone, with no value present - e.g., a Date property gets range inputs, a string gets a literal/regex choice, an Object gets additive "has property X" controls. Reading a search widget back produces a serializable query object (an AND/OR tree of typed leaf constraints), not an in-memory predicate function, so it can be stored, sent over the wire, or handed to a host to translate into a real query (MongoDB, sift(), IndexedDB, etc.).

Query vocabulary

The query tree borrows MongoDB's own operator names ($and/$or, $gt/$gte/$lt/$lte, $in/$nin, $regex/$options, $exists) wherever a leaf kind has a clean Mongo equivalent, so a host can adapt the common cases to sift() (or real MongoDB) almost for free. This is not a claim of full drop-in Mongo query-document compatibility:

• Every leaf keeps jsoe's own kind-discriminated, path-carrying shape, not Mongo's field-keyed document shape.
• Several jsoe-specific leaf kinds - blobHTML, domShape, keyValueEnum, mapRecordJoint, typeOf, passThrough - have no Mongo equivalent and stay custom.
• The $ prefix is the tell for which vocabulary a field belongs to: a $-prefixed field maps onto a real Mongo operator, while an unprefixed one (kind, path, and type-specific extras like searchType, mode, isInteger) is jsoe's own invention, with no Mongo equivalent to borrow.

Why the query needs its schema

A query node is not fully self-describing in isolation - it is meant to be read back alongside the schema it was built from, not as a standalone format. Most leaf kinds don't repeat type information the schema already carries at that path; the deliberate exception is range's own valueType field, needed because five different schema types (number, NumberObject, bigint, date, buffersource) share one leaf shape, and two of them (bigint, date) even serialize their bounds as the same JS type (a plain string) - without valueType, a host couldn't otherwise tell a bigint range from a date range from the leaf alone. A host executing these queries should always keep the originating schema on hand, rather than treat the query tree as a fully independent, schema-free format.

This isn't applied evenly, though. range's valueType is an explicit, self-contained tag - a host only has to check one field. Several composite widgets instead rely on position, not any tag at all: regexpSearchType.js combines its source leaf (regex/literalSet/notContains) with an optional flags leaf at the same path via one $and (combineAnd([sourceLeaf, flagsLeaf])), so a bare multiSelect leaf found there means "flags" only because a host already knows regexp's own fixed two-leaf convention - nothing on the leaf itself says so, unlike range. The same bare multiSelect shape is also how enum/SpecialRealNumber express their own constraints at their own paths, so the leaf kind alone is never enough; a host needs both the schema type at that path and, for composite widgets like regexp, that type's own specific leaf-combination convention, to know what a given leaf means.

Known issues

• Cannot provide maps with object keys pointing to the same objects as used as map values; likewise with Sets?
• Certain cyclical structures may have issues
• typeson-registry's structured cloning should throw on more objects, so bad data doesn't end up stored
• Currently doesn't support using isNullable; instead just use null with a union.
• Lacks support for certain Structured Cloning types. See to-dos below.
• Excessive use of reportValidity (e.g., in BufferSource, as seen by index-instrumented demo) causing focus of element; should only be triggered by event (and only if not auto-triggered event)

To-dos

1. Ability to replace content with Safe Eval (no functions in default mode, etc.)/AI (including speech-to-text) if it validates
2. Expand fundamental types
   1. Not in typeson-registry
      1. Structured Cloning
         1. Web/API types (besides those listed below)
            1. See https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Structured_clone_algorithm#webapi_types
   2. Already in typeson-registry
      1. Structured Cloning
         1. (JavaScript types already complete)
         2. Web/API types
            1. quotaexceedederror
            2. webtransporterror
            3. imagedata
            4. imagebitmap
            5. domquad
            6. cryptokey
            7. audiodata
            8. encodedaudiochunk
            9. encodedvideochunk
            10. videoframe
            11. gpucompilationinfo
            12. gpucompilationmessage
         3. Our own custom derivative types? (e.g., MIDI using TypedArray)
3. Expand subtypes
   1. String
      1. As supported by Zod, JSON Schema, etc. (e.g., email addresses as subtype of string, color as a subtype of string)
   2. File/Blob
      1. Drawing image for image/png, etc. File's
      2. Drawing SVG program for application/svg File
      3. JS/CSS/HTML/XML/Markdown/JSON/CSV/text text editor (including syntax highlighting in view mode); with text-to-speech
      4. OCR (TextDetector API if implemented) added as image pop-up utility
4. Might put views and data into separate repos
5. Could show more schema data (e.g., min and max) in viewUI, e.g., as extra rows in the schema meta info toggle
6. Implement as Custom Elements?
7. Add drag-and-drop support for File type
8. Import CSV as array
9. Schema-driven search
   1. Optional
      1. Might allow "Edit as raw" as JSON6 (edit query object directly) on each individual object/array/map/tuple/record/filelist
      2. Could add syntax highlighting for CSS Selector, XPath, Regexes
      3. Error, Special Errors, DOMException: Literal search of child string properties
      4. Might allow search on .cause and AggregateError.errors in the future
      5. date, number, NumberObject, bigint, bigint object, BufferSource: Is Not Range
      6. instanceof, Non-editable (no variants to allow for distinct search; if optional, would be in union); non-editable might allow arbitrary JS query against it, but...
      7. symbol (description), string, StringObject: literal match
      8. Blob, File: OR literal or regex search/Does Not contain search on contents