Str — string utilities
JavaScript’s String prototype has a rich set of methods, but they’re all data-first: you call
them on the string itself, which doesn’t compose inside pipe. Str provides the same operations
as data-last curried functions, plus two safe parsers that return Maybe instead of NaN.
Transforming case
Section titled “Transforming case”Str.toUpperCase and Str.toLowerCase are direct data-last wrappers — pass them to pipe or
Arr.map:
Cleaning input with trim
Section titled “Cleaning input with trim”Str.trim removes leading and trailing whitespace:
In a validation pipeline, trim is typically the first step before any pattern checking.
Splitting strings
Section titled “Splitting strings”Str.split splits a string by a string or regex separator, returning a readonly array:
For splitting into natural words or lines, Str.words and Str.lines handle whitespace and
line-ending edge cases for you.
Splitting into lines and words
Section titled “Splitting into lines and words”Str.lines splits a string into lines, normalising \r\n, \r, and \n endings — useful when
parsing multi-line text from different sources:
Str.words splits a string on any whitespace boundary, trims both ends, and filters out empty
tokens — no need to chain trim + split + filter:
Predicates for filtering
Section titled “Predicates for filtering”Str.includes, Str.startsWith, and Str.endsWith are curried predicates that work directly
with Arr.filter:
Safe number parsing
Section titled “Safe number parsing”Parsing a number with Number(s) or parseInt returns NaN on failure, which propagates
silently. Str.parse.int and Str.parse.float return Maybe<number> instead:
This integrates with the Maybe API for safe fallback handling:
Composing it all
Section titled “Composing it all”Str functions are designed to appear as steps in a pipe chain alongside other operations:
When to use Str
Section titled “When to use Str”Use Str when:
- You’re composing string operations inside a
pipechain and want point-free style - You’re filtering or mapping arrays of strings and want named predicates instead of inline lambdas
- You’re parsing numeric strings from user input, query parameters, or configuration and need a
typed
Mayberather than aNaNcheck - You’re splitting multi-line or whitespace-separated text and want consistent handling of edge cases
Keep using the native String prototype methods when:
- The operation is a one-liner in a function body where the method call is already clear
- You need locale-sensitive operations (
localeCompare,toLocaleLowerCase, etc.) - You don’t need the result to compose in a pipeline