mozey/ft

Flexible types^[1] for un-marshaling any JSON^[2] value.

This package builds on

• null.* types in guregu/null
• sql.Null* types in database/sql

Numeric types (Int, Float) wrap 64bit base types, e.g. int64 and float64.

For each basic type, this package implements two flexible types^[3], for example

• required struct fields may use ft.String, it supports flexible types when un-marshaling.
• optional fields may use ft.NString, it supports both flexible types and allows NULL. Think of the N-prefix as meaning "allows null", or "not-required"

type data struct {
    Required ft.String `json:"required"`
    Optional ft.NString `json:"optional"`
}

Above data struct can be used to un-marshal the following JSON

{
    "required": 123,
    "optional": null
}

NULL is not considered valid, for example

b := []byte(`{"required": 123,"optional": null}`)
d := data{}
err = json.Unmarshal(b, &d)
fmt.Println(d.Required.Valid)  // true
fmt.Println(d.Required.String) // "123"
fmt.Println(d.Optional.Valid)  // false
fmt.Println(d.Optional.String) // ""

Both custom types in this package, allowing NULL or not, embed structs with the same fields. For example

// String
s := ft.StringForm(123)
fmt.Println(string(s.Valid)) // true
fmt.Println(s.String)        // 123
// NString
s := ft.NStringForm(123)
fmt.Println(string(s.Valid)) // true
fmt.Println(s.String)        // 123

After un-marshaling, the Valid field may be toggled by your custom validation code.

Flexible types can be used with the templating packages. Either of the types above, String or NString, could be used in this text template example

t1 = template.Must(t1.Parse(`{{if .Valid }} The value is .String {{end}}`))
t1.Execute(os.Stdout, s) // The value is 123

Tests

See tests for more usage examples

cd ${PRO_PATH}
git clone https://github.com/mozey/ft.git
cd ${PRO_PATH}/ft
go clean -testcache && go test -v ./...

Reference

[1] Not quite the same concept as Flexible typing in SQLite. Note that "as of SQLite version 3.37.0 (2021-11-27), SQLite supports this development style [Rigid Type Enforcement] using STRICT tables"

Previously this repo used the term "fuzzy types". It was renamed, and the term replaced with "flexible types". To avoid confusion with fuzzing, a new feature added to the "standard toolchain beginning in Go 1.18"

[2] JSON spec

[3] This repo does not use generics, and will compile with older versions of Go