Ability to organize params in groups

[protozoo]

Is it possible to organize params in groups, so that they are easier to find/use in the side panel? I haven't found it in the documentation, so I assume it's not? I if it's not, I think it would be a good addition. Maybe it could be controlled with an additional attribute to the para definition object, i.e.:

$fx.params([
  {
    id: "number_id",
    name: "A number",
    type: "number",
    group: "My Group Name"   // <-- Name of the group this param belongs to
  }]);

Then, the params UI could show the group name in a slightly larger font size and the associated params below.

[danieljulia]

I fully support this petition. When you have a lot of params would improve radically the usability of the interface. Maybe the groups could be also collapsible.

[digitallyserviced]

I am on your side, but I am not... lol

So I want to start off by saying that this comes from my experiences so far as a creator on fxhash (albeit not tons), but the tons of experience from having 20+ years coding/sysadm/devop/engi career.

I actually fullly support the ability for creators to have more control and customization abilities for their GENTKs (fx)params and a collectors usage of (fx)lens to iterate generations of the pieces.

My experience thus far with (fx)lens hasn't been more than 2 personal projects, but I have done work for and with a few other artists. This usually involved converting their p5 or vanilla JS sketches, and integrating the fxhash API/snippet and/or (fx)params.

However, my very first creation, was published during a time of (fx)lens version fragmentation with the version in repo, the version used on the site, and the sandbox/publishing/upload wizards not actually using (fx)lens proper for controlling the params sliders/fields/values while testing.

While everything up to the point of clicking "Finish" had operated properly.

Apparently there was an issue with the "default" field of a number data type. This caused Zod to fail validating the field as a number

I have a PR for attempting to coerce fields to number as well).

https://github.com/fxhash/fxlens/blob/3072a24eabce046dc5061452c01397bc44b8d6f8/src/components/FxParams/validation.ts#L15C1-L20

Now while this could be resolved by the PR, I am relying on fxhash to actually accept it.

Then my reliance is on their future features, fixes, PR submissions and any other changes will not cause any ill effects with projects prior to the change.

(My coercion could cause it to parse into something oddball like -Inf or -0 and now specific projects prior act differently)

Any changes or additions to the (fx)lens customization abilities for (fx)params most likely will require more control of the defined (fx)params schema, data types available and their (de)serialization handling to be changed as well.

tldr; While (fx)lens is a great utility for manipulating values, and objects within a sketch to be able to customize/test/iterate generations, I think that it should be downplayed as the "main" UI/UX for the minting process.

The user's experience for more complex interactions with token customization, should fall on the creator and the project/token that is published/uploaded.

fxhash has given us the tools to do this already. The code-driven vars, the API to integrate and communicate them, and the ability to determine in what context your project is being viewed in (minting,standalone,preview).

I really would rather see the ability to remove elements from (fx)lens, and get out of the way. There are var configuration UI's that are much easier, more capable, featureful, prettier, and customizable then (fx)lens.

tweakpane

react-var-ui

DAT.gui