Using SolidJS Dev-Tools Locator Feature

In my previous article I went through how to get the SolidJS Dev-Tools up and running with your application. I covered the Debug feature which allows you to debug the reactivity graph, and also the Logger which lets you log more specific events within the framework (like effect re-executing etc.)

In this post I’m going to dive into the Locator feature which is supposed to allow “locating components on the page, and going to their source code in your IDE.”

---

The Babel Transform Plugin

Before I do that I wanna fix something which kinda bugged me before and also acts as an enabler for the Locator to work. If you remember, when opening the debugger you had a lot of “weird” names to the signals, which looked like “s606947053”:

As @thetarnav (the dev-tools project’s maintainer) mentioned to me, there is a solution for that which involves a Babel plugin that extracts the given name so it can later be parsed by the debugger. Let’s give it a go -

Following the docs I’m installing the Babel plugin:

yarn add -D @solid-devtools/transform

(Notice I’m installing it as a dev dependency)

Next I will add the required configuration to my project’s vite config, like so:

import {defineConfig} from 'vite';
import solidPlugin from 'vite-plugin-solid';
import devtoolsPlugin from '@solid-devtools/transform';

export default defineConfig({
   plugins: [
       devtoolsPlugin({
           jsxLocation: true,
           name: true,
       }),
       solidPlugin(),
   ],
   build: {
       target: 'esnext',
       polyfillDynamicImport: false,
   },
});

Since I don’t have a store here I’m not using the “wrapStores” option, but only the jsxLocation and the name. Refreshing the application and I can see names of my signals -

Yep, here is “cursor” and bufferGap”. Noice.
Moving on to the Locator feature…

The Locator

So now that we got better names for signals it is time to check out the Locator feature.
As I mentioned before, you need to have the babel transform plugin set, with the jsxLocation enabled.

The docs say to “configure it by calling useLocatorPlugin with some options”, which is great but the question remains - where?!
I will go with what I think makes the most sense, that is the project’s entry point, which now looks like this:

import 'solid-devtools';
import {render} from 'solid-js/web';

import './index.css';
import App from './App';
import {useLocatorPlugin} from 'solid-devtools';

useLocatorPlugin({
   key: "shiftKey"
   targetIDE: 'vscode',
});

render(() => <App />, document.getElementById('root'));

And after refreshing, when I’m holding the shift-key I see the related component I’m hovering on:

That’s nice, and when clicking it BOOM!, my VSCode IDE is opened at the right place for the highlighted component.
If you open and inspect the elements on the page, you will see that each relevant one has a data-source-loc attribute to it which holds the file path, line and column of the source code:

Sweet :)

Dev Mode

You would probably want things like the Locator executing only when developing a feature, and not on production. Solid has this nice “DEV” feature that you can query and make decisions according to.
If we would like to use the Locator plugin only in dev, you should probably do this:

import 'solid-devtools';
import {render} from 'solid-js/web';
import {useLocatorPlugin} from 'solid-devtools';
import {DEV} from 'solid-js';
import {isServer} from 'solid-js/web';
import './index.css';
import App from './App';

if (DEV && !isServer) {
   console.log('In DEV mode');
   useLocatorPlugin({
       targetIDE: 'vscode',
   });
}

render(() => <App />, document.getElementById('root'));

Wrapping up

Well… the Locator allows you to quickly navigate to your component. You can also have a callback there and do whatever you want with the given arguments. Aside from that, just seeing the component real name on the browser when you hover it is enough for you to get started quickly.
Code can be found in this GitHub repo.

As always, if you have any comments or questions, be sure to leave them in the comments below.

Hey! If you liked what you've just read check out @mattibarzeev on Twitter 🍻

Photo by Andres Siimon on Unsplash

Comments

[Damian Tarnawski]

Heyy, Thank You for another article on the devtools!
This is a really helpful insight to what the docs should contain, and how to present it in a understandable way. If you (or anyone else) think that there is something missing, be sure to make an issue or a PR to make it a little bit better for the next person :)
Here is a tip regarding the "Dev Mode": all of the runtime packages (debugger/locator/logger) have a separate export for production (similarly to solid itself) where the functions that that you call in your code only work in dev—in production they are noops. So you don't have to put it behind a if statement yourself.

[Matti Bar-Zeev]

Thanks :)
That's a great tip about the dev mode! So I guess you don't have to have this condition for that 👍