- var request and var response in Init() → const (never reassigned,
var is function-scoped and hoisted which is undesirable in class methods)
- let formData in UploadChunk() → const (never reassigned)
- chunkResponse in UploadChunk() removed (assigned but never read)
- let start in GetChunks() → const (never reassigned)
- var percent in UpdateProgressBar() → const (never reassigned)
document.querySelector() can return null if the elements are not
yet in the DOM. Dereferencing null would throw inside the axios
onUploadProgress callback, which is caught by UploadChunk's catch
and re-thrown as a string - causing the whole upload to fail
silently with an undefined message.
UploadChunk throws a template literal string, not an Error object.
Accessing .message on a string primitive returns undefined, so
JSOnUploadError was always called with undefined and the server log
showed no useful detail. Use String(ex) as fallback so the message
is always populated.
The original catch block was simply swalloing errors instead of
propagating them upwards.
When the /api/Upload/Init request failed it set this.Key = null, logged
to the console, and returned normally. From the caller's perspective
Init() had succeeded.
Start() in the Blazor component then called Upload() immediately after,
which proceeded with this.Key = null. Every chunk was sent to the server
with a null key, the server returned 400 for each one, each UploadChunk
call threw, and the whole upload failed - but only after sending every
chunk, and only with the opaque "Error uploading chunk N/M" message
rather than anything pointing at the actual cause.
By removing the catch, an axios error in Init() propagates up through
the JS interop call InvokeVoidAsync("Init", ...) in Start(). That throws
a JSException in C#, Start() exits immediately before Upload() is ever
called, and the finally block resets Uploading so the UI recovers. The
user gets a failure where it actually happened.
bundle.js is built by webpack as an ES module (output.library.type:
'module'), ending with named exports such as:
export { Be as ChunkUploader, s as InfiniteScroll, ... }
All three inclusion sites (App.razor, _Layout.cshtml,
ScriptLoader.razor) loaded it via a plain <script> tag, which is for
classic scripts only and does not support the 'export' keyword.
Edge throws a visible SyntaxError and uploading does not work.
Fixed by adding type="module" to the bundle.js script tag in all three
locations.
- Chat messages are now loaded based on scroll position
- Read status is now updated and set by last message read
- Reworked script importing by using ScriptProvider
- Load thread after creation
- Change thread list from DataList to Flex
- Move unread badge to right side of chat thread list item
- Fix avatar rerendering after another message is added to message group
- Add styling to thread list
- Change message input to support markdown and add markdown rendering for message contents
Using the required keyword to indicate what is expected to be passed to the components in the stack.
Looking through the usage, only the Values property can come through as null, everything else is set to something that should never be nullable (and then, if it is, it should be considered a proper error to resolve).
