---
# System prepended metadata

title: Dev-tools Extension

---

# Dev-tools Extension
A Dev-tools extension to enhance Developer and QA's experience to test lightning apps.

## Problems

What problems are we trying to solve with this project?

### # Application debugging

As much as our application has grown, it's become harder and harder to test specific scenarios without click around the app.

Another example is the feature flag system we have in place. It's based on query param:

```
http://localhost:8080?flag=profile&flag=mouse&flag=clear_local_storage
```

This is a bit tedious and error prone. If you misspel a flag, there's no good indication that this flag is invalid.

Also, people have to remember by heart and when it's QA, they either have to open our codebase (not ideal) and/or ask to some dev about X flag.


---



### # Lightning debugging

We currently have no structured way of checking a Lightning component's API, state, and styles.

If we compare our setup with competing mainstream frameworks such as React or Vue, we are missing several key debugging tools. 

**Examples**
- [Vue Devtools](https://chrome.google.com/webstore/detail/vuejs-devtools/nhdogjmejiglipccpnnnanhbledajbpd?hl=en)
- [React Developer Tools](https://chrome.google.com/webstore/detail/react-developer-tools/fmkadmapgofadopljbjfkapdkoienihi?hl=en)

---

Below we've listed some of the main features that could benefit our team - many of them present in other frameworks:

#### >> Feature Wishlist

- Tree view / Element viewer
    -  "Inspect Element" -> Create outline on screen for the component.

        Comparison to when we as developer want to enable "native lightning" debug mode currently: In a nuthshell you need to load in a JS script which gets the current element application tree and creates DOM nodes which represents the current structure of the canvas. This is a really nice strategy, specially for new team members to easily see and understand how Lightning renders the application tree.

- Component view
    -  Property manipulation
    -  State manipulation
    -  Style interaction
    -  Event inspector

- Application interaction
    -  Reload application
    -  Router debugger

- Performance view
    - Display internal Lightning information present but not visible to devs:
        - Application heap memory
        - Current memory consumption
        - Escape hatch to clear memory
        - Memory timeline / chart



## Principles


## Architecture


### Persistency

Our application currently does not provide a persistent way to test a specific feature. Reload the application, and the feature flag is gone.

Given that, we could introduce a debug-specific application configuration that only gets loaded if the DEBUG flag is present. 


### Reactivity

Lightning does not offer reactivity. The closer we get from that is by using `redux` and connecting our component into a store.

Given that, a `devtools` store should be created containing the most simple `key/value`:

```js
const store = {
    feature_profile: true,
    feature_mouse: true
}
```

And then whoever wants to consume those values would necessarily have to connect itself to our `connect` function and, when this value got changed, the component itself will also be updated.


## FAQ

<details>
<summary>
    <strong>Why not a browser extension?</strong>
</summary>

Although it seems a good idea there are some important cons to avoid this path.

The first is to avoid having a lot of spread tools. It means that nobody will need to install anything to take advantage of the devtools no matter who they are. Second, QAs run our software most on TV (browsers) and there's no way of installing a browser extension there.

In that sense, having the devtools as part of the application would enable anyone, anywhere, using it to put the application in a very specific state.
</details>

<details>
<summary>
    <strong>Why not use the Lightning DevTools?</strong>
</summary>

The dev-tools [provided by the Lightning team](https://github.com/rdkcentral/Lightning/blob/master/devtools/lightning-inspect.js) is cumbersome and hard to integrate into our application work-flow.

Also, it's not solving the majority of the challenges we see on a daily basis when debugging.
</details>