Closed lilactown closed 4 years ago
As a potential user of this lib, I like the purely syntax-based option the most. hx.react/fnc*
could walk the body and warn if symbols beginning with use
or <-
are used in disallowed contexts. Might be hard to enumerate the allowed vs disallowed contexts though.
Off topic and feel free to disregard entirely, but I don't find that <-
is an improvement over use
. "<-" doesn't obviously translate to "use" - without looking at docs I would think it means something closer to "take", and use
has the advantage that it's what react already uses.
That’s good feedback. I liked the look of <-
at the beginning because it made the syntax stand out, and also was similar to a syntax someone proposed somewhere (can’t find it rn) that was like:
function MyComponent(props) {
let counter << state(0);
...
}
I do think that there could be some sort of syntax that is more evocative of what Hooks do - hooking into the component’s render cycle and doing some sort of side effect - but the drawbacks of using <-
in the function name is starting to grate. For instance, they show up as garbage in React DevTools.
I guess that begs the question: what should we use as the standard? Should we do camel case useXyzAbc
? Or kebab-case use-xyz-abc
? I’m kind of leaning towards keeping the React idiom in general. Hmm.
My 2 cents: the closer to React the better. In naming it makes no sense to differentiate, doesn't bring any advantage.
On Sat, Apr 13, 2019, 7:32 PM Will notifications@github.com wrote:
That’s good feedback. I liked the look of <- at the beginning because it made the syntax stand out, and also was similar to a syntax someone proposed somewhere (can’t find it rn) that was like:
function MyComponent(props) {
let counter << state(0);
...
}
I do think that there could be some sort of syntax that is more evocative of what Hooks do - hooking into the component’s render cycle and doing some sort of side effect - but the drawbacks of using <- in the function name is starting to grate. For instance, they show up as garbage in React DevTools.
I guess that begs the question: what should we use as the standard? Should we do camel case useXyzAbc? Or kebab-case use-xyz-abc? I’m kind of leaning towards keeping the React idiom in general. Hmm.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Lokeh/hx/issues/34#issuecomment-482847170, or mute the thread https://github.com/notifications/unsubscribe-auth/AAEt3rFlqUmYA-76Xf4uVPnxTTjEJL2Mks5vghSZgaJpZM4bnZ6G .
Per the React docs:
The React team has released an eslint plugin that helps enforce these rules.
I think it would be interesting to see how we could help CLJS developers follow these same conventions.
Here are some considerations:
hx
and foreign code (e.g. npm libraries, CLJS libs that don't use hx)hx
😅My initial thought was a
hooks
macro that was similar tolet
, but to enforce that hooks can't be used outside of that macro, detect if hooks are being used in loops, etc.We could do some silly things, like:
React.useState
,React.useEffect
etc. to only work if inside ahooks
block. This would break any external libs trying to use Hooks 😛hx.hooks
namespace This would have inconsistent behavior with 3rd party codePerhaps having it be purely syntax level would be best: e.g. it looks for either
<-
oruse
at the beginning of the symbol name, then enforces the top-level rules of hooks.I'm not sure how we would enforce that Hooks must only be used in React component functions or custom Hooks in this case.
Posting this issue here to collect thoughts!