> Markdown version of [Debugging a Web Component Integration](https://vaadin.com/docs/v10/flow/web-components/debugging-a-web-component-integration). Section index: [llms.txt](https://vaadin.com/docs/v10/flow/llms.txt)

# Debugging a Web Component Integration

Not everything is smooth sailing and sometimes the component just refuses to work like you want it to. If the problem is on the Java side, you can use your standard IDE debugger to figure out what happens but when the problem is in the browser, it gets a bit trickier. Chrome Inspector is an invaluable tool when trying to figure out what goes wrong.

## <a id="is-the-element-not-configured-as-it-should"></a>Is the element not configured as it should?

Check with the DOM inspector that the element contains the expected attributes (most of the time properties are synchronized to attributes and vice versa). If the property is not synchronized to an attribute, select the element in the inspector and write `$0.somePropertyName` in the console to check that the value is the expected one.

## <a id="is-an-event-not-sent-to-the-server-as-you-would-expect"></a>Is an event not sent to the server as you would expect?

Select the element, and write `monitorEvents($0,'event-name');` in the console. You will now see a log row if the event is triggered and will know you have the correct event name and that the web component actually fires the event. You can leave out `'event-name'` to log all events but be prepared to see a lot of `mousemove` events. You can also use this to see which properties are defined for the event so that you can know what to include in `@EventData`

## <a id="do-you-need-to-debug-the-javascript"></a>Do you need to debug the Javascript?

If you need to debug what the web component does, use the browser debugger to set breakpoints at suitable places. In more problematic cases, e.g. if the problem occurs on initial setup, you can add a `debugger;` statement to the web component code to make the browser always and automatically break at that point. To do that, you need to get a editable copy of the web component included in your project. One way is to unzip the files from the webjar you are using into the location used by Flow. As the add-on project is a `jar` project it has no `src/main/webapp` folder where you can place static files, instead Jetty is configured to use `src/test/webjar-debug/META-INF/resources` as the webapp folder. This particular folder is chosen so you can unzip a webjar directly into `src/test/webjar-debug` and those files will be used instead of the files in a web jar.

To debug the `increment()` function in `paper-slider` you can thus do:

1. Unzip `paper-slider-2.0.6.jar` into `src/test/webjar-debug`, e.g. `unzip ~/.m2/repository/org/webjars/bowergithub/polymerelements/paper-slider/2.0.6/paper-slider-2.0.6.jar -d src/test/webjars-debug/`

2. Add a `debugger` statement to the `increment: function() {` function

3. Restart Jetty, click on the "Increment" button when the inspector window is open

> **Tip:** Disable the cache in the browser network tab to avoid getting old versions of the files you are debugging.