How Telixon works
Google libphonenumber’s metadata is compiled ahead of time into a single deterministic finite automaton (DFA), stored as binary tables. Every answer about a phone number comes from that automaton.
Parsing
Section titled “Parsing”Parsing is a walk over the automaton, one digit per step. The state the walk ends on determines the region, the number type, whether the number is valid, and how to format it.
const number = parsePhoneNumber('+1 (415) 555-0132');// the walk has already happened
number.getRegion(); // 'US'number.getNumberType(); // 'FIXED_LINE_OR_MOBILE'number.isValid(); // trueValidity
Section titled “Validity”A number is valid when the walk ends on an accepting state. That is the whole definition. Everything else is a classified failure, returned as a typed value:
parsePhoneNumber('5550132', { defaultRegion: 'US' }).getValidationError();// { kind: 'POSSIBLE_LOCAL_ONLY' }Seven digits form a US number that connects only inside its own area. The walk ends on a state that
records exactly that. The nine variants are in
ValidationError.
Parser and controller consistency
Section titled “Parser and controller consistency”parsePhoneNumber walks the automaton once, over a whole string. An input controller walks it
again on every keystroke, over the value as it stands. It is the same walk, which makes their
answers agree by construction. A controller can hand you a PhoneNumber at any moment, mid-typing.
const controller = createInternationalInputController();controller.setValue('+1 (415) 555-0132');
controller.getPhoneNumber().formatE164(); // '+14155550132'parsePhoneNumber('+1 (415) 555-0132').formatE164(); // '+14155550132'Consequences
Section titled “Consequences”- Bad input does not throw. A walk always ends somewhere. Where it ends is the result.
- Formatting can return
null. The formats follow possibility. A number whose calling code or length can never work has no format to give. - The engine loads first. Without the tables there is nothing to walk.