mirror of
https://github.com/yewstack/yew.git
synced 2026-01-25 16:43:15 +00:00
* Add doc-test to test website code snippets Heavily inspired by tokio-rs/website repo. * Fix code snippets to pass doc tests Some code snippets are explicitly ignored and some are not run to avoid having to include dependencies for one liners. * Add website code snippet tests to CI * Fix CI * Remove doc-test from workspace * Exclude doc-test from workspace * Refactor code snippets and tests Code snippets can import types from doc_test crate i.e.: ```rust use doc_test::agents::EventBus; ``` This allows for moving some boilerplate away from the example and still checks that the code compiles correctly. Also some slight changes to some of the examples and the information about `ComponentLink` which is deprecated. * Move doc-test to packages * Rename doc-test crate to website-test The new name makes it more clear the purpose of this crate. * fix ci
47 lines
2.0 KiB
Markdown
47 lines
2.0 KiB
Markdown
---
|
||
title: "Debugging"
|
||
---
|
||
|
||
## Panics
|
||
|
||
The [`console_error_panic`](https://github.com/rustwasm/console_error_panic_hook) crate catches
|
||
`panic!`s and outputs them to the console. Yew will automatically catch `panic!`s and log them to
|
||
your browser's console.
|
||
|
||
## Console Logging
|
||
|
||
In general, Wasm web apps are able to interact with Browser APIs, and the `console.log` API is no
|
||
exception. There are a few options available:
|
||
|
||
### [`wasm-logger`](https://crates.io/crates/wasm-logger)
|
||
|
||
This crate integrates with the familiar Rust `log` crate:
|
||
|
||
```rust ,ignore
|
||
// setup
|
||
fn main() {
|
||
wasm_logger::init(wasm_logger::Config::default());
|
||
}
|
||
|
||
// usage
|
||
log::info!("Update: {:?}", msg);
|
||
```
|
||
|
||
## Source Maps
|
||
|
||
There is currently no first-class support for source maps for Rust / Wasm web apps. This, of course, is subject to change. If this is no longer true or if progress is made, please suggest a change!
|
||
|
||
### Latest Info
|
||
|
||
\[Dec 2019\] [Chrome DevTools update](https://developers.google.com/web/updates/2019/12/webassembly#the_future)
|
||
|
||
> There is still quite a bit of work to do though. For example, on the tooling side, Emscripten \(Binaryen\) and wasm-pack \(wasm-bindgen\) don’t support updating DWARF information on transformations they perform yet.
|
||
|
||
\[2020\] [Rust Wasm debugging guide](https://rustwasm.github.io/book/reference/debugging.html#using-a-debugger)
|
||
|
||
> Unfortunately, the debugging story for WebAssembly is still immature. On most Unix systems, [DWARF](http://dwarfstd.org/) is used to encode the information that a debugger needs to provide source-level inspection of a running program. There is an alternative format that encodes similar information on Windows. Currently, there is no equivalent for WebAssembly.
|
||
|
||
\[2019\] [Rust Wasm roadmap](https://rustwasm.github.io/rfcs/007-2019-roadmap.html#debugging)
|
||
|
||
> Debugging is tricky because much of the story is out of this working group's hands, and depends on both the WebAssembly standardization bodies and the folks implementing browser developer tools instead.
|