Should I condense my hooks output array?

Hey guys, so I have my useValidation function and it returns the following array.

return [sync, isPropertyValid, watch, update, focus];

return [sync, isPropertyValid, watch, update, focus];

So 5 items in the array, but it seems like generally speaking the first 2 are the ones most frequently used like so

export default function Home() {
  const [syncInput, isPropertyValid] = useValidation(AccountValidation);

  return (
    <>
        <input
          {...syncInput("username")}
          style={{
            border: !isPropertyValid("username")
              ? "thick double red"
              : "thick double rgba(0,0,0,0)",
          }}
          type={"text"}
          placeholder={"Enter your name"}
        />
    </>
  );
}

export default function Home() {
  const [syncInput, isPropertyValid] = useValidation(AccountValidation);

  return (
    <>
        <input
          {...syncInput("username")}
          style={{
            border: !isPropertyValid("username")
              ? "thick double red"
              : "thick double rgba(0,0,0,0)",
          }}
          type={"text"}
          placeholder={"Enter your name"}
        />
    </>
  );
}

Should I condense my 5 item array into something smaller like this

const actions = {watch, update, focus}

return [sync, isPropertyValid, actions];

const actions = {watch, update, focus}

return [sync, isPropertyValid, actions];

Or do you think its better to leave it as 5?

14 Replies

Neto•2y ago

you can split into two blocks

const [syncInput, { isPropertyValid }] = useValidation(thing);

const [syncInput, { isPropertyValid }] = useValidation(thing);

randoDev•2y ago

or just return an object. I feel better knowing what I'm using when there are more than 2 things

const { syncInput, isPropertyValid } = useValidation(thing);

const { syncInput, isPropertyValid } = useValidation(thing);

MagerXOP•2y ago

I had considered that but I didn't want to complicate the potential for multiple useValidations in a component. Granted I'm not sure why you would do that lol but I didnt want to hamper potential use cases that I hadn't thought of However in hindsight, I decided my long term plan is to aggregate slices together into one slice, so maybe an object output is the move

Brendonovich•2y ago

If anything this is the best reason to use an object, so that instead of destructing you can just assign it all to a variable and essentially namespace each validator’s stuff by the variable names

randoDev•2y ago

I didn't want to complicate the potential for multiple useValidations in a  component

I didn't want to complicate the potential for multiple useValidations in a  component

I'm not sure if I follow what you mean. What does having multiple useValidations is a component have to do with it returning an array or an object? I just like object for #props > 2 because I get autocomplete and select what I need on the left side, instead of having to read what it returns and fish out specific index of the thing you are looking for React Query does this too with number of prop it returns name spacing things can also be done with array too you just return object as element

const [first, secObj] = ["first", {a:"a",b:"b"}]

const [first, secObj] = ["first", {a:"a",b:"b"}]

but like I said, why not just object

MagerXOP•2y ago

My concern was I wanted to enable people to do something like this if they ever had a need, but in hindsight, I actually don't intend to support this because its not likely that a user will do it. But I was thinking about this

export default function Home() {
  const [syncInput, isPropertyValid] = useValidation(AccountValidation);
  const [sync, isValid] = useValidation(UserValidation);

  return (
    <>
        <input
          {...syncInput("username")}
          style={{
            border: !isPropertyValid("username")
              ? "thick double red"
              : "thick double rgba(0,0,0,0)",
          }}
          type={"text"}
          placeholder={"Enter your name"}
        />
    </>
  );
}

export default function Home() {
  const [syncInput, isPropertyValid] = useValidation(AccountValidation);
  const [sync, isValid] = useValidation(UserValidation);

  return (
    <>
        <input
          {...syncInput("username")}
          style={{
            border: !isPropertyValid("username")
              ? "thick double red"
              : "thick double rgba(0,0,0,0)",
          }}
          type={"text"}
          placeholder={"Enter your name"}
        />
    </>
  );
}

With array destructuring, the end user isnt stuck with a hard coded name that I decided, instead they get to utilize something they selected. But yeah I think I'm gonna nix it favor of

 const {sync, isValid, /* actions */} = useValidation(UserValidation);

 const {sync, isValid, /* actions */} = useValidation(UserValidation);

Also, follow up question For validation declaration, which feels more intuitive.

const AccountValidation = Validation.createValidationSlice({
  username: Validation.new("").not().length(5, 10),
  email: Validation.new("").length(2, 200).includes("@"),
  phone: Validation.new("").length(9,10).match(/[0-9]*/).optional(),
  password: Validation.new("").match(reg),
  confirmPassword: Validation.new("").custom((val) => val.length > 5);
});

const AccountValidation = Validation.createValidationSlice({
  username: Validation.new("").not().length(5, 10),
  email: Validation.new("").length(2, 200).includes("@"),
  phone: Validation.new("").length(9,10).match(/[0-9]*/).optional(),
  password: Validation.new("").match(reg),
  confirmPassword: Validation.new("").custom((val) => val.length > 5);
});

const AccountValidation = Validation.createValidationSlice({
  username: Validation.new("").not().length(5, 10).required(),
  email: Validation.new("").length(2, 200).includes("@").required(),
  phone: Validation.new("").length(9,10).match(/[0-9]*/),
  password: Validation.new("").match(reg).required(),
  confirmPassword: Validation.new("").custom((val) => val.length > 5)..required();
});

const AccountValidation = Validation.createValidationSlice({
  username: Validation.new("").not().length(5, 10).required(),
  email: Validation.new("").length(2, 200).includes("@").required(),
  phone: Validation.new("").length(9,10).match(/[0-9]*/),
  password: Validation.new("").match(reg).required(),
  confirmPassword: Validation.new("").custom((val) => val.length > 5)..required();
});

` To simplify the question, should required be explicit or implicit.

randoDev•2y ago

you can rename them as follows, this is exactly how you use multiple useMutation/Query hooks of ReactQuery

const {sync: userSync, isValid:userIsValid, /* actions */} = useValidation(UserValidation);
const {sync: emailSync, isValid:emailIsValid, /* actions */} = useValidation(EmailValidation);

const {sync: userSync, isValid:userIsValid, /* actions */} = useValidation(UserValidation);
const {sync: emailSync, isValid:emailIsValid, /* actions */} = useValidation(EmailValidation);

I prefer .optional() If you have it in the validator that is not marked optional, then it must be required. This level of implicitness I don't feel like its abstracting much if at all.

Brendonovich•2y ago

please for the love of god don’t destructure and just give each object a name

MagerXOP•2y ago

lol I definitely dont intend too, I was just repeating the previous pattern for my question

Brendonovich•2y ago

good good

randoDev•2y ago

Maybe "exactly how you use" is strong opinion of mine, would you share why you are opposed to destructuring? I'm guessing possibly more stack space, undefined(but we know the object shape here) variable, and clutter? wondering if there is anything I'm missing

Brendonovich•2y ago

Destructuring some stuff is fine, but at Spacedrive we’ve pretty much banned destructuring useQuery/useMutation/useForm returnss It’s bc of exactly what you did in that snippet, where you aliased each field to have a name specific to the validator it’s used for When you only have one thing to destructure it’s fine, but when u destructure multiple things with the same fields and have to individually alias all of them it looks terrible So we enforce that you just give the object a name and use that to namespace the fields, dotting in really isn’t that bad In very limited circumstances we allow it (eg. satisfying eslint with useEffect dependency arrays) but in general we require that those things can’t be restructured

randoDev•2y ago

gotcha yeah I can imagine more than 2 things its better to do just dot

MagerXOP•2y ago

I kinda missed that last about the implicit statement. What about it seems like a bad/poor abstraction? and what do you think could be done to improve it?

Gaming

Programming

Should I condense my hooks output array?