https://linen.dev logo
Join Discord
Powered by
# react
  • a
    I came back to it
  • a
    This works :)
  • a
    hacky but ah well
  • a
    yay finished with updating the native_base externs 😊
  • u
  • u
    Uh, not a good example since it allows anything else x) you'll want to return null instead of 
    expr
  • u
  • a
    it's not the primary usecase to create an additional prop to pass down
  • a
    i can't define a prop called 
    in
    in a typesafe way because it's a keyword in haxe
  • a
    so wrapping the extern and modifying the prop at runtime is the best solution i could think of
  • u
    What I linked does exactly that: - define an extern component which accepts an 
    in
    prop - allow you to do 
    <MyExternComponent in={foo} />
    in your jsx - get it to send "in" prop in js, without runtime overhead
  • a
    oh hm i don't understand the code then
  • u
    With that, you don't define your 
    in
    prop in your props typedef (because it doesn't work properly), but instead hook a macro that will check props that were not recognized and allow (+ pass) any prop named "in" (with typechecking iirc)
  • u
    The doc link explains it better I hope x) (read until the end, the next section is what you're after)
  • a
    i read the doc but i'm not sure i got the interpretation you wanted me to get, i thought props were type checked pretty well in jsx
  • a
    also, this is a library, isn't an init macro something that is added in the users code base?
  • a
    I guess i can add that to the extern as well 🤔
  • a
    but in the doc i saw nothing that indicates this kind of use, i'll have a play with it :3
  • a
    and initmacro is a bit cryptic, 
    if (some_condition)
    what is this condition meant to be? 🤣
  • a
    am i meant to make the assumption that I have to determine that the the 
    expr
    and the 
    name
    match up?
  • u
    if (name == "in")
    ?
  • u
    expr
    will be what is passed as value to the 
    name
    prop So you check if 
    name
    is recognized, and generate 
    ($expr :ExpectedTypeForThisProp)
    and compiler does the type checking Then this will be set to 
    name
    prop
  • a
    aaahhh
  • a
    i get it
  • a
    it works, but i'm gonna stick to the runtime overhead because this appears to very reliably, break completion/diagnostics 😂
  • a
    compiles fine, and restarting the language server fixes this
  • a
    but the error comes back rapidly or every time you reboot vscode
  • a
    I think i'd prefer just commenting the props to use a different field in place of the default approach 😆
  • u
    Oh nice catch, will try to find time to handle that
  • u
    Haxe and react?
1...636465...80Latest