With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js. Learn more →
Sum-types Alternatives
Similar projects and alternatives to sum-types
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
immutable-js
Immutable persistent data collections for Javascript which increase efficiency and simplicity.
-
mori
ClojureScript's persistent data structures and supporting API from the comfort of vanilla JavaScript
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
eslint-plugin-expect-type
ESLint plugin with ^? Twoslash, $ExpectError, and $ExpectType type assertions. 🧩
-
lambda-ioc
Discontinued Super type safe dependency injection 💉 for TypeScript (inspired by Diddly)
sum-types reviews and mentions
-
Either type
I entirely agree about using symbols. sum-types does that.
-
Question about error handling in Typescript
With fp-ts and sum-types you'd handle this functionally like so:
-
type .kind checks vs. class instanceof checks
If you're looking to have discriminated unions like Rust, follow that section to roll your own or look for a library that's already implemented them. fp-ts has everything under the sun in a Haskell style, neverthrow has Rust-like Result and ResultAsync, and sum-types helps with the boilerplate of defining your own sum types.
-
Is there a more graceful way to create dependencies between object key settings?
I'd suggest sum-types. Instead of unsafe user-defined type guards you get safe pattern matching.
-
Best way to store persistent texts?
If you wanted to lean (more) into FP you could replace the Event type and buildPopup function with a sum type and pattern match respectively, as well as represent side effects like in popup with fp-ts' IO, make use of function composition, etc. The former in particular is great for readability:
-
Is there any known way to measure coverage of... types?
You can test types, at least in terms of asserting happy path types and whether a piece of code, runtime or purely type-level, should trigger a tsc type error. Here's an example using eslint-plugin-expect-type.
-
Has the unsoundness (will explain in the post) actually become a pitfall in practice?
Anywhere that overloads are needed will rely upon type assertions or the unsafety implicit in overloads, for example in fp-ts/function::pipe. It'll come up a lot with objects too when there isn't a preexisting primitive you can compose atop of, as in for example fp-ts-std/Record::pick. Something as generic as @unsplash/sum-types has assertions all over the place, though to be fair that's mostly again a case of struggles interacting with object types.
-
How to handle "mutable state" in a pure functional way
You might like @unsplash/sum-types also.
-
A note from our sponsor - SurveyJS
surveyjs.io | 24 Apr 2024
Stats
unsplash/sum-types is an open source project licensed under MIT License which is an OSI approved license.
The primary programming language of sum-types is TypeScript.
Sponsored