deps: use new aura-js

[Fang-]

Summary

Move to using the new aura-js from urbit/aura-js#8.

Opening this as an RFC. General questions/concerns/feedback welcome, see below for specific questions.

Changes

Updates the usage of @urbit/aura in /apps/tlon-web and /packages/shared. I haven't done the rest yet, and the code here assumes you've npm linked the aura-js PR, but the changes here should be sufficient to evaluate.

Questions:

1. I originally had parse aliased to slaw (returning bigint | null) rather than slav (returning bigint or throwing). iiuc old parsing logic tended to throw too, so we now maintain parity, but is that our ideal/desire?
   • Do you want a parseMaybe alias for slaw? Or a better/more standard name?
2. We don't expose any "is valid aura" helpers. So far it seems we only do that for @ps, and such checks are trivially implemented as checking slaw output for null. Thought? Do we want dedicated helpers?
   • Dedicated helpers may be slightly faster by skipping the actual parsing logic, but for some auras (like @p) validating and parsing are basically the same step, and I haven't looked for or seen evidence that the whole is slow enough to matter, anyway.

How did I test?

Compiles and passes basic smoke testing. Will do further testing once things settle.

Risks and impact

New aura-js includes bugfixes for some rendering and parsing edge cases, so doesn't have exact parity with the current one. This primarily affects rendering of @uw, @q for zero or leading-zero cases, and rendering & parsing of @da. I suspect that all cases that matter have parity, but we should keep an eye out regardless.

Particularly sensitive to that are cases where we store client-generated string representations of atoms in db/client state. Do we do any of that? Which ones?

• Sure, safe to rollback without consulting PR author.
• Affects important code area:
  • Onboarding
  • State / providers
  • Message sync
  • Channel display
  • Notifications
  • Other: probably all of the above

Rollback plan

Revert.

[arthyn]

no comments lgtm

[latter-bolden]

old parsing logic tended to throw too, so we now maintain parity, but is that our ideal/desire?

I'd generally prefer parse failure throw as a default. Makes it clear that there was a failure and avoids null/falsy value ambiguity. All the better that it was generally the behavior before.

Do you want a parseMaybe alias for slaw? Or a better/more standard name?

Would recommend that we alias slaw. parseMaybe is fine, tryParse is perhaps more idiomatic

We don't expose any "is valid aura" helpers... Thought? Do we want dedicated helpers?

Agree it's important for @p since we process those as raw user input. I don't think there's an immediate need for others. Maybe once we're doing more funky stuff with input values for hooks? But that's fairly speculative..

affects rendering of @uw, @q for zero or leading-zero cases, and rendering & parsing of @da

• @q we don't use
• @uw we use selectively (noun channels, lanyard, metagrab) and can verify before merging.
• @da probably is the most "load bearing" of the bunch (scry endpoints, optimistic IDs)

cases where we store client-generated string representations of atoms in db/client state. Do we do any of that? Which ones?

The only thing that comes to mind is %lanyard. Does anything in nounParsers scare you? I can't think of anywhere besides noun channel interactions where we'd work with client generated atoms. If received, we'd always treat as opaque values elsewhere.

Overall I think the new API feels cleaner, nice work :)

[latter-bolden]

@Fang- I think we'll need to set this to the released @urbit/aura upgrade to make CI go green. Let me know once that's out!