Tracking props and their values

[mihkeleidast]

Hey! Nice tool you have here. I'm currently analyzing using this for our needs and comparing it to react-scanner and the like.

One feature that seems to be missing here is detailed props and prop values usage tracking. The usecase is likely self-evident, but to be clear: we want to know what props and values are used and where, so we could analyze what is used/unused, and make deprecation/removal decisions based on that.

Any plans to add such features?

[smoogly]

Short answer is yes, I'd like to, but unfortunately I can't give you an estimate of when.
When would you like to make a call about the tools to use? What ballpark of a promise for getting that feature will make you choose this tracker?

The underlying problem is how to account for cases where props aren't known.
This might happen, for example, with render props:

import { Table, Heading, Cell } from "lib";
export const SpecificTable = ({ data }: { data: ReadonlyArray<unknown> }) => <Table heading={ Heading } cell={ Cell } data={ data }/>

What are the props of Heading and Cell?
I suppose we could categorize them as "unknown" in what is a comparatively rare case.
But you still won't know if a certain prop combination is used without taking a deeper look into those cases.

There's a similar problem with completeness when using react-scanner, but from a slightly different angle.
Last time I checked, it used simple AST traversal to match components to their respective imports. This means that the code below wouldn't be counted as a usage:

import { Component } from "lib";
const Renamed = Component;
export const Result = () => <Renamed/>;

[mihkeleidast]

Short answer is yes, I'd like to, but unfortunately I can't give you an estimate of when.
When would you like to make a call about the tools to use? What ballpark of a promise for getting that feature will make you choose this tracker?

Well, ASAP would be good :) I'm also happy to contribute if we can align on a technical direction (and I can grok the setup here).

Since it's one of our main requirements, we wouldn't pick radius-tracker if this ask was a straight "no". If it's coming down the line (or we can contribute) it would be a big pro for radius-tracker.

It is supported in react-scanner, but they output a huge JSON that needs to be parsed/split to a database by us after the fact. What I like about radius-tracker is that it outputs basically a ready-to-go database, which seems more plug-and-play (so less additional work for us).

The underlying problem is how to account for cases where props aren't known.
This might happen, for example, with render props:

import { Table, Heading, Cell } from "lib";
export const SpecificTable = ({ data }: { data: ReadonlyArray<unknown> }) => <Table heading={ Heading } cell={ Cell } data={ data }/>

What are the props of Heading and Cell?
I suppose we could categorize them as "unknown" in what is a comparatively rare case.

Yep, I would think that saying "unknown" or whatever the AST name for it is would be fine. It can always be improved upon later on, if we find solutions - for example, maybe the value can be stringified in some way.

I believe Omlet also does the same - just says that it's a "complex value" or something like that.

But you still won't know if a certain prop combination is used without taking a deeper look into those cases.

That's true, but I agree that these are somewhat rare cases and it's fine if we need to manually take a look at specifics. The important part is that we know that the prop is used on that instance, so we at least know where to look.