Feature: more robust module loader for router
**I'm submitting a ...** (check one with "x") ``` [ ] bug report [x] feature request [ ] support request ``` **Current behavior** The router's current default module loader tries once and crashes the app if it fails to retrieve the module. That's not good in a mobile environment where **latency and connectivity may be intermittent or poor.** We are always more robust when designing for data requests. **We should ship a default loader that is more robust in the face of connectivity failures** A counter argument is that _we should do what the browser does with scripts ... we should fail_. The argument continues: _loading data is different from loading a module_. I disagree. If a script fails to load, the app never even starts. When lost connectivity is the cause, the HTML fails to load too and the user sees the familiar 404. The user cannot have accumulated unsaved work. Lazy loading and even preloading of modules can occur after the app has been running for some time. The user may be deep into a work flow when connectivity drops. If it were a data operation, the developer would have prepared for this possibility and found a way to keep the app alive and preserve unsaved work. The reasoning is the same for failed module loading. One might argue that the developer who cares about this should create a custom loader. That's a fine response if we were talking about unusual circumstances. I think we are talking about an environment that is so common we should handle it
Posted by wardbell on Oct 14, 2016, 1:05 AM
Tags
Related issues
- I hate that this whole cluster of beliefs exists, but software on my own computer enforcing what I can and can't do for ideological reaso...
- As I replied in another comment[1], it's their software, their choice.
- [Feature] Support external model integration via personal API keys and local LLMs (BYOK)
- > So when head of companies don’t care about quality, they’ll push hard no matter what to have speed.
- Feature request: support multiple named accounts per app/connector
- Support standalone Windows installer (`codex-setup.exe`)
Raise real-world problems, find people facing the same issue, and discuss solutions.4,500 issues0 comments
support (SaaS)
I hate that this whole cluster of beliefs exists, but software on my own computer enforcing what I can and can't do for ideological reaso...
As I replied in another comment[1], it's their software, their choice.
[Feature] Support external model integration via personal API keys and local LLMs (BYOK)
> So when head of companies don’t care about quality, they’ll push hard no matter what to have speed.
Feature request: support multiple named accounts per app/connector
Support standalone Windows installer (`codex-setup.exe`)
[feature]: Move OIDC back to self-hosted OSS(Plane Free)
I was running about 1000 machines on VMware in my previous career.
Feature: more robust module loader for router
**I'm submitting a ...** (check one with "x") ``` [ ] bug report [x] feature request [ ] support request ``` **Current behavior** The router's current default module loader tries once and crashes the app if it fails to retrieve the module. That's not good in a mobile environment where **latency and connectivity may be intermittent or poor.** We are always more robust when designing for data requests. **We should ship a default loader that is more robust in the face of connectivity failures** A counter argument is that _we should do what the browser does with scripts ... we should fail_. The argument continues: _loading data is different from loading a module_. I disagree. If a script fails to load, the app never even starts. When lost connectivity is the cause, the HTML fails to load too and the user sees the familiar 404. The user cannot have accumulated unsaved work. Lazy loading and even preloading of modules can occur after the app has been running for some time. The user may be deep into a work flow when connectivity drops. If it were a data operation, the developer would have prepared for this possibility and found a way to keep the app alive and preserve unsaved work. The reasoning is the same for failed module loading. One might argue that the developer who cares about this should create a custom loader. That's a fine response if we were talking about unusual circumstances. I think we are talking about an environment that is so common we should handle it
Comments (0)
No comments yet. Start the discussion.