inlang project: async function calls should be async

[samuelstroschein]

Problem

• treating async operations sync will lead to bugs in apps
• awaiting async operations with a dedicated init() is unergonomic

The reactive system treats async operations like inlang.lint.reports as sync operations leading to the requirement to call await inlang.lint.init() before accessing lint reports. Awaiting init is arguably inconvenient and will definitely lead to "gotcha" moments. More importantly though, awaiting init will lead to bugs.

Example

The production code below struggles with awaiting an update operation and introduces a workaround by awaiting a promise that will eventually resolve. A gateway to bugs by thinking "this is sync, why is my message not immediately update?", forgetting to establish such a workaround, maybe the timeout is too fast, etc.

https://github.com/inlang/inlang/blob/3c4b975a47c427dbb8cbdf565eedca0a75cdd0da/source-code/core/app/src/wrappers/withSolidReactivity.test.ts#L259-L261

[samuelstroschein]

Proposal - Treat async as async

Getting lint reports or updating messages are async operations and treat them as such.

Pros

• no more init concept/footgun (the first call to inlang.lint.reports for example will "initialize" under the hood)
• no more sync operations that are async and need to be awaited with workarounds

Cons

• await is required but to execute functions but hey those operations are async anyways

// on first call, the lint system is initialized. subsequent calls are immediately resolving. 
await inlang.lint.reports()

// awaiting a message update that will resolve once the message is updated
await inlang.query.messages.update()

// treating query as async has another benefit: we open the door for lazy fetching of messages in the future 
await inlang.query.messages.get()

Additional information

• !!! We can make async ops sync again in the future but can't make sync ops async (breaking change)!!!
• we might be able to introduce async incrementally by first removing init() and then sometime in the future make await query.messages.update() "truly async"/at first immediately resolve the promise
• solid has a async reactive solution called createResource which might solve our issue

[ivanhofer]

I was also going to suggest that mutation operations should be async.
We have introduced the init command to not run all lints immediately when createInlang get's called. If we can avoid this, then we should get rid of the init command as it is yet another concept to explain. I'm just not sure if making the getter async leads into other problems.

[NilsJacobsen]

Agree, while using it in the badge, I felt like people are not going to understand that without the docs. Or at least they will wonder why this needs to be done.

[samuelstroschein]

@ivanhofer We have introduced the init command to not run all lints immediately when createInlang get's called. If we can avoid this, then we should get rid of the init command as it is yet another concept to explain.

We can leave the lazy linting by resolving the first call to await inlang.lint.reports() only after lints are initialized.

I'm just not sure if making the getter async leads into other problems.

What problem(s) would occur?

[ivanhofer]

I haven't thougt of it yet, so not sure if there are some

[samuelstroschein]

@inlang/team another day another problem.

i used discussions to enable better multi-proposal conversations (the proposal is not part of the problem description)

[samuelstroschein]

Progress is tracked in #1290