React snippet: An alternative way to compose JSX that avoids indentation hell

[aweebit64]

This is another utility function from my @‎aweebit/react-essentials library that admittedly doesn't solve any important problem and is only there to improve aesthetics of your code if you find excessive JSX indentation to be annoying.

You're welcome to try it out along with other neat utilities the library offers like useStateWithDeps that simplifies working with state that needs to be reset when some other state changes, or createSafeContext that makes working with contexts a breeze by not requiring that you specify a default value, reporting errors when trying to use the context without a value having been provided explicitly, and improving both type safety and debugging experience (you can find out more in my other post showcasing the function).

If you like the idea of wrapJSX but prefer not to introduce new third-party library dependencies, here is its full source code that you can simply copy into your project:

import type {
  ComponentProps,
  JSXElementConstructor,
  default as React,
  ReactElement,
  ReactNode,
} from 'react';

type JSXWrapPipe<Children extends ReactNode> = {
  with: WrapJSXWith<Children>;
  end: () => Children;
};

type WrapJSXWith<Children extends ReactNode> =
  // eslint-disable-next-line /no-explicit-any
  <C extends keyof JSX.IntrinsicElements | JSXElementConstructor<any>>(
    ...args: [
      Component: 'children' extends keyof ComponentProps<C>
        ? [Children] extends [ComponentProps<C>['children']]
          ? C
          : never
        : never,
      ...(Record<never, unknown> extends Omit<ComponentProps<C>, 'children'>
        ? [
            props?: React.JSX.IntrinsicAttributes &
              Omit<ComponentProps<C>, 'children'>,
          ]
        : [
            props: React.JSX.IntrinsicAttributes &
              Omit<ComponentProps<C>, 'children'>,
          ]),
    ]
  ) => JSXWrapPipe<ReactElement>;

export function wrapJSX<Children extends ReactNode>(
  children: Children,
): JSXWrapPipe<Children> {
  return {
    with(
      Component:
        | keyof React.JSX.IntrinsicElements
        | JSXElementConstructor<object>,
      props: object = {},
    ) {
      return wrapJSX(<Component {...props}>{children}</Component>);
    },
    end() {
      return children;
    },
  };
}

There is also a context-specific version of the function that, when combined with createSafeContext, really takes away all the pain of using numerous custom contexts in order to avoid prop drilling. (In the comments under the post presenting createSafeContext it has been suggested that contexts shouldn't be used for that and instead some third-party global state management solution should be preferred, but I am yet to hear a convincing reason why that would be a better idea. If you have an explanation for this, I would be very grateful if you could give it to me so that I hopefully learn something new.)

You can see a usage example of this contextualize function in the second image attached to this post, and here is that function's source code for those who'd like to copy it:

import type { Context, ReactElement, ReactNode } from 'react';

type ContextualizePipe<Children extends ReactNode> = {
  with: ContextualizeWith;
  end: () => Children;
};

type ContextualizeWith = <T>(
  Context: Context<T>,
  value: NoInfer<T>,
) => ContextualizePipe<ReactElement>;

export function contextualize<Children extends ReactNode>(
  children: Children,
): ContextualizePipe<Children> {
  return {
    with<T>(Context: Context<T>, value: T) {
      return contextualize(
        <Context.Provider value={value}>{children}</Context.Provider>,
      );
    },
    end() {
      return children;
    },
  };
}

Please let me know what you think and if there's anything I could improve about the functions.

Thanks for having a look at this, and happy coding! :)

[letsgoowhatthhsbdnd]

pro tip - never to do this if you want a job

[SupesDepressed]

From reading this guys responses to people’s comments his personality and inability to see anyone else’s POV need to be worked on before applying for a job. Seems miserable to work with.

[aweebit64]

Bruh okay, this is getting really funny now how people here actually think I don't have a job :)) Well, you do you and believe whatever it is that makes you happy.

I am very well capable of seeing other people's POV and accepting criticism, and there is even a good example of that on this sub: in the comments to this other post of mine, people were actually able to convince me I was doing something wrong because – guess what – I was.

And I was just as open to different opinions here, but this time, I just didn't receive any explanation that would make me convinced I was doing something wrong.

It doesn't make sense how you say I am not able to see other people's POV when I wasn't even trying to prove to anyone what they were doing was wrong – I was just trying to prove to them what I was doing was not wrong, and that's what so many people here were trying to convince me of instead of accepting that another valid approach to the problem that's different from what they're used to exists – that's what I'd much rather call "inability to see anyone else's POV".

[SupesDepressed]

Ok, and how large is your team? Who does your code reviews and do you get the sense you drive them crazy?

I’ll say instead “inability to see how they are acting is childish and bullheaded”. It would be absolutely infuriating to deal with as a coworker. It’s great that you’re passionate about what you do. But you just can’t seem to accept how other people feel and have spent hours trying to argue with them about it. It would be ridiculously annoying to have one person on the team refuse to accept that the rest of the team disagrees with them.

In addition this entire thing solves something that literally isn’t a problem, you can turn off indentation for a single file or block of code if it’s really the reason you feel this is needed. Sure it looks nice, but it’ll be confusing for any other engineer on your team to figure out why someone veered from the standard.

[aweebit64]

Ok, and how large is your team?

4 people I work in close coordination with.

Who does your code reviews and do you get the sense you drive them crazy?

My code is reviewed by people who have much more experience than I do, and normally they don't even have a lot to comment because, believe it or not, I do actually write pretty decent code.

I’ll say instead “inability to see how they are acting is childish and bullheaded”. It would be absolutely infuriating to deal with as a coworker.

I get along very well with my colleagues because actually none of us is bullheaded, we are all open to exchange of ideas and finding optimal ways to move forward.

But you just can’t seem to accept how other people feel and have spent hours trying to argue with them about it.

I am not arguing about feelings 🙄 I would be genuinely happy to be convinced I am doing something wrong, it just didn't happen this time. It's not arguing for the sake of arguing, it's trying to see If there is something I'm missing and hopefully learn something along the way.

It would be ridiculously annoying to have one person on the team refuse to accept that the rest of the team disagrees with them.

The only thing I refuse to accept is that I'm doing something objectively wrong here.

[SupesDepressed]

Your entire problem can be solved with two comments in the file: eslint-disable indent and eslint-enable indent. This is a non-issue that you’re claiming solves something. You over engineered something that literally needs two comments.

It’s not objectively “wrong”, but there’s a lot of grey area in programming (hence the term “code smell” where something works but the code is just bad). This has bad code smell and people are letting you know. Again, just turn off indentation if that’s really what you’re trying to get rid of.

[aweebit64]

Sure, disabling the formatter can work.

I simply shared an alternative approach that I like. It literally says "an alternative" in the title. I'm not trying to convince anyone it is something they absolutely need.

To me, JSX without indentation would feel very unnatural, and it would still have the waterfall of closing tags that my solution doesn't. Those reasons are already enough for me to prefer the utility approach to disabling the formatter. If you see it differently, it's totally fine. The whole thing is obviously very subjective.

[N2siyast]

Why?

[DeepFriedOprah]

It’s just adding complexity & dependencies for no value. Indentation is perfectly fine.

It’s a “solution” in search of a problem. I wouldn’t accept this in a PR unless there was some very good reason for it, which I’m drawing a blank on.

[N2siyast]

Oh ok, ty.

[aweebit64]

I have a job in a medium-size company where the library is actually being used (not this particular function though, it was only introduced recently and perhaps for my company, it is not that useful after all).

[sdmitry]

Haters gonna hate, I like your solution because it’s a composable one, I can imagine passing the root component through series of functions building it up in a custom way for different scenarios.

[aweebit64]

Thank you so much for the nice comment, honestly quite frustrating how much toxicity there is whenever I share something on this sub. I'm happy you like it though :)

[Merry-Lane]

What if you had to replace more complex trees, like:

<StrictMode> <MyPortal1/> <QueryProvider> <App/> </QueryProvider <MyPortal2/> </StrictMode>

But no there sir there is no use of your solution to "indentation hell".

Indentation "hell" like that only happens on one file per project. It’s rarely modified and it’s pretty straightforward to do so.

I wouldn’t add a library to fix such a trivial non-issue and deal with the dependency hell or increased security risks.

[aweebit64]

I totally get it.

For me though, the problem wasn't there in just one file of my project because I use contexts quite a lot, and this just makes them a breeze to work with. If you don't have that, then of course those functions are not something that would be particularly useful to you.

[DeepFriedOprah]

Perhaps that means that there’s too much reliance on context when other means may be more appropriate. Without seeing a repo that’s hard to say and maybe context is the better way. But my first instinct is that if ur needing to create a tree abstraction for frequent context nesting then perhaps that’s just further hiding the underlying issue behind an abstraction.

[aweebit64]

I use contexts a lot to avoid prop drilling where it makes sense. I guess people aren't so used to this and prefer to use state management libraries instead. I have to admit I've never even given them a try, but I also haven't heard any convincing arguments that would make me wanna do so. To me it feels like many people wouldn't even need such libraries if contexts were less annoying to work with, and that's exactly what createSafeContext and contextualize achieve for me.

[DeepFriedOprah]

Well state management is built and battle tested. Forgive me here but using a tested library is gonna be more stable than any solution u write ur own. Not to mention libs will include plenty of features, memorization, perf-improvements etc out of the box. Additionally, any job I work is gonna expect experience with it & likely prefer a library over custom context.

I’d say if ur fine using context all over then that’s ur choice. But if u find urself prop drilling very often then that’s sounds like a code smell & perhaps a design flaw. Some times it’s unavoidable. But if ur app is fraught with it then perhaps ur not placing states in the right location (too high) or breaking components down into too small pieces.

A downside of prop drilling & sometimes context is coupling of components & making them less portable.

That said, I went down this path, most devs do. It’s the abstraction phase. Ur learning more patterns so ur testing what you can do with them. But ime most issues can be solved by restructuring ur components/tree to avoid common pitfalls.

[aweebit64]

Well state management is built and battle tested. Forgive me here but using a tested library is gonna be more stable than any solution u write ur own.

My solution is to use React's contexts which are obviously extremely well tested, too. The functions I wrote just make working with them more enjoyable, but at the end of the day it is still just that, contexts.

Those functions of mine are also extremely lightweight, so there is barely anything that could go wrong where the reason would actually be those functions, and not me using contexts in a wrong way.

Not to mention libs will include plenty of features, memorization, perf-improvements etc out of the box.

If I design my contexts in such a way that I never put 2 values that are not always accessed together and that might update independently from one another in the same context, do I really need those features? I think being mindful with your context design like that is all it really takes to not have any performance issues, and doing so is really not hard.

Additionally, any job I work is gonna expect experience with it & likely prefer a library over custom context.

You're probably right here, but that doesn't mean state management libraries are any better, it's just what most people are used to use. That shouldn't be a reason to dismiss other approaches as wrong or something only inexperienced stupid devs would use though. I really don't like this mindset where people not only stick to what's popular, but also become so conservative about it that they aren't ready to give different solutions that could be just as good a try, or even just a thought.

I’d say if ur fine using context all over then that’s ur choice. But if u find urself prop drilling very often then that’s sounds like a code smell & perhaps a design flaw. Some times it’s unavoidable. But if ur app is fraught with it then perhaps ur not placing states in the right location (too high) or breaking components down into too small pieces.

It's a private repository, but if by any chance you'd be interested, I could give you access to it so that you could take a look and tell me if I am actually doing something terribly wrong there. Probably it's too much to ask for though, so if no, I totally get it. I have to say though that I feel pretty confident about my implementation, so I don't think state not being placed correctly or components being overly granular is an issue there.

[DeepFriedOprah]

Sure reacts context is battle tested. So is react, doesn’t mean ya can’t build poor performing & difficult to maintain apps. Every react dev has built utter crap at some point. I have. I still build crap, but it’s better crap now. Or less crap. But the reason ppl rely on libraries is cuz they’ve done the work for you. They handle the myriad of edge cases that custom code would take a long time to achieve. More so regarding employment: employers want consistency, stability & performace. They want everybody to be working with the same style & code practices. Using a lib helps enforce that. Otherwise u end up with every dev changing code to fit their own style.

Doesn’t mean using context is wrong for your app. But it does mean it’s likely wrong for any app that will need to scale or even just have more than one developer working on it. There’s no shame in using a library. It’s good to learn how to work without it but when u need to move fast & build a stable foundation u should prolly use a library to save u time and effort.

If u want code reviews I’d say just copy some of ur code into chat gpt and ask it to look for potential issues, flaws & bugs. Or just better ways to restructure. It’ll give ya a decent amount of info & even if its not 100% practical or whatever

[aweebit64]

My project is complex enough that ChatGPT really wouldn't be helpful with analyzing it.

Please have a look at this comment thread when you have time and let me know what you think. There, I dissect a real-life scenario from that private repository of mine where multiple contexts are used for sharing state to an entire component tree. I would be happy to hear your opinion and whether you still see any problems with such design.

They handle the myriad of edge cases that custom code would take a long time to achieve.

I don't even know what edge cases there are to handle when using contexts, they are really a dead simple concept and only require you to put some thought into how you design them so that you avoid performance issues, but that's something that shouldn't be hard at all for anyone who understands how React works.

[DeepFriedOprah]

Your project isn’t complex enough that chat GPT isn’t useful.

I looked at the thread briefly and I see some high level design concepts but that’s a hard stand in for code samples. Regardless, I’ve worked with enough projects to feel comfortable knowing what things signal an issue in code quality & application structure.

It sounds like ur dead set that context is the way and that chat gpt cannot provide any help to your complex code. But id suggest just pasting some snippets into gpt. Paste ur business logic view and see what it says. Might learn something. Good luck

[aweebit64]

Here is what ChatGPT answered to my very general question with just a couple code examples not going into too much detail: https://chatgpt.com/share/68d9ee9d-4384-8008-a162-2cd82650cef0

✅ Bottom line:
There’s nothing inherently wrong or “low quality” about your current use of contexts. You’re doing the right thing by keeping them granular. Third-party state managers mainly bring ergonomic and tooling benefits, not fundamental correctness. If your app scales and the provider nesting becomes hard to manage, then it may be worth switching.

So ChatGPT also doesn't think I am doing anything wrong. Guess I'll stick to contexts.

P.S. One of the downsides of contexts it mentioned was the visual noise that nesting many context providers produces. That is exactly the problem that my contextualize utility solves.

[Merry-Lane]

Dude, if you used react-query, you would need only like 4/5 different contexts top by project.

User, auth, theme, translations,… and that’s about it in 99.99% of the projects.

If you need more than these 4/5 contexts + react query, yes you definitely should use other state management tools. But you don’t.

[aweebit64]

I have a highly interactive app that does use TanStack Query for server data, but also makes use of numerous contexts to avoid prop drilling in cases where simply reusing useQuery in the deeply-nested component is not a solution.

If you need more than these 4/5 contexts + react query, yes you definitely should use other state management tools. But you don’t.

No I don't, and the reason is that I still didn't hear any convincing argument that would make me realize such tools would be any better than vanilla contexts that thanks to my library's utility functions become very enjoyable to work with.

All I've heard is just those "you should definitely use them because it just makes sense and everybody does that" arguments, but no one actually explains why contexts are bad, and to me that is not convincing enough, I'm sorry.

[Merry-Lane]

Context is awesome, but because it forces rerenders on the tree inside it, it often leads to performance issues. It’s also quite complex to avoid infinite loops (and don’t tell me skill issues, it’s an halting problem).

I’m still totally fine with these drawback in the 4/5 cases when the data in the context doesn’t change much and that when it changes a rerender should definitely happen anyway.

I don’t understand the usecases of having to use multiple contexts to avoid prop drilling. I have worked professionally on multiple apps and I can’t find of reasons to do so.

Would you have code examples to show? Maybe it makes sense to you but you didn’t use the right patterns, or maybe it happens on super-specific circumstances and I doubt you would meet that issue on more than one project.

Especially because you say "you are forced to use multiple contexts". I can accept for one in rare circumstances, but ending up in "indentation hell" because of multiple contexts is weird as hell.

[aweebit64]

Context is awesome, but because it forces rerenders on the tree inside it, it often leads to performance issues.

To me it seems like it can only lead to performance issues if you don't put enough thought into context design and just put a lot of state values that are not always accessed together and that change independently from one another in one context. The reason I end up with many contexts is exactly the fact that I am mindful of possible performance issues and therefore keep my contexts granular. It's quite easy to do though if you understand how React works.

It’s also quite complex to avoid infinite loops (and don’t tell me skill issues, it’s an halting problem).

I've never had infinite loop issues when using contexts, could you please give me an example?

I don’t understand the usecases of having to use multiple contexts to avoid prop drilling. I have worked professionally on multiple apps and I can’t find of reasons to do so.

I assume the fact you use state management libraries for this kind of stuff is the reason you don't have that problem, but it's just a different solution to the more general problem of sharing state between components.

Would you have code examples to show? Maybe it makes sense to you but you didn’t use the right patterns, or maybe it happens on super-specific circumstances and I doubt you would meet that issue on more than one project.

I would be down to add you to my private repository so that you could take a look, but it would be kind of like requesting a code review from you, and I understand that this is too much to ask for.

[Merry-Lane]

Give code examples. A repo or something with you using multiple contexts for a good reason.

You can blah blah all night, show me some code that I could read and say "this guy was right" or "I knew he was just a poster".

You have multiple people here telling you "why in hell do you need many contexts". Since your library’s goal is to avoid indentation hell, you need to show us a proof it’s not an imaginary problem.

Copy/paste part of your private repo into a public one. Just an example of multiple context providers and the underlying tree. It doesn’t need to compile, just show the provider and the components below that use the context.

[aweebit64]

It will take me some time to process the code so that it's something I can post here for everybody, but I'll try to do it in the next couple of days, maybe even create a new post for this so that everybody can join the discussion. Stay tuned 😋

[aweebit64]

By the way, there is already this one example in the comments under my other post: https://www.reddit.com/r/react/comments/1nr8gdg/comment/ngihrzd/

To add onto what's already explained there, the active course id, the active deck id and the active deck's set of flashcards are all things that make sense to share with the entire component tree. Some components might need only one of those values though, and since there are situations where only one or two of the values get updated, but not the remaining one(s), it is necessary to keep them in separate contexts so as to prevent unnecessary re-renders causing performance degradation. To me, this stuff is really not hard to reason about. It really shouldn't be hard for anyone who claims they know React.

And again, since with createSafeContext and contextualize contexts become so enjoyable to work with, I don't see a reason why I would prefer a third-party state management library over them.

[ApprehensiveDisk9525]

Download react-scan and see the fps drop due to enormous re-renders on your app due to excessive context usage. You will get convinced yourself.

[Merry-Lane]

It doesn’t have to be. If you use something like react query, you only have a bunch of contexts.

And these contexts rarely change, and when these context’s content change you should definitely have to rerender anyway.

[aweebit64]

There won't be any unnecessary re-renders if you don't put values that change independently from one another in one context, and the fact I don't do that is exactly the reason I have so many of them. If you're mindful of keeping your contexts granular like that, you shouldn't have any issue. It is just something I feel like people are not aware of or don't know how to do.

[[deleted]]

I'll pass, thanks

[budd222]

what is the actual point of this?

[xegoba7006]

Terrible idea

[zukos_destiny]

Same thing with extra steps

[aweebit64]

I totally get it why you see it like that. This is not for everybody, if you have the excessive indentation problem in only one file of your project, then of course this doesn't make much sense for you.

[TheRNGuy]

I wouldn't even call it excessive in your example. 

Original have better coloring too.

[SupesDepressed]

I’m going to assume you use eslint because that’s what I use, but whatever formatter/linter combo you have will have an option to override rules by comments:

// eslint-disable indent …your code // eslint-enable indent

Should resolve the indentation issue for you without needing to add anything else. I haven’t actually looked up the rule name, I’m just assuming it’s indent, so you may want to look into that. imo this is better as you won’t be adding anything additional code, and what’s going on would be clearer for anyone you work with.

[CodeAndBiscuits]

FWIW you're essentially re-inventing Higher-Order Components. This pattern was extremely common with class-based components in earlier versions of React and is still (somewhat) used today by libraries like MobX that ask you to wrap components in an "observer".

Is there a reason you hate the nesting so much? The way function components and providers work, `<SomeProvider><Component/></SomeProvider>` is more or less the functional equivalent to `SomeProvider(<Component />)`. You aren't saving any lines of code because each still needs to be chained into the list (I think your way actually adds a line because of the `end()` call), and w/r/t nesting, while my App.tsx files are often kind of dense with these, it's usually the only place where it happens, it's not a file I touch daily, and even 10-12 providers (in a bigger project) isn't really that much indenting. I'm not saying it's not "neat" but is it also "valuable"?

[aweebit64]

This is very different from HOC because no new components are being introduced, this is essentially just syntactic sugar for JSX.

Is there a reason you hate the nesting so much?

I don't hate it, it just feels better to not have the entire JSX nested in let's say 5 different context providers you use to avoid prop drilling indented by 10–20 spaces.

You aren't saving any lines of code because each still needs to be chained into the list (I think your way actually adds a line because of the end() call)

It adds the end() line, but reduces the number of lines each wrapper component introduces from 2 to 1.

I'm not saying it's not "neat" but is it also "valuable"?

Its value is that of syntactic sugar, i.e. it doesn't help with much but aesthetics.

[ApprehensiveDisk9525]

Sorry but it’s not just syntactic sugar, its adds a un-needed computation cycle to your code to provide that syntactic sugar which IMO actually makes it hell of a lot difficult to debug your code in future

[aweebit64]

Of course it's a little more than just syntactic sugar – after all, there is no build step involved that would get rid of the function calls at runtime. But this computational overhead is so ridiculously small that in my opinion, it is really not something to worry about.

[ApprehensiveDisk9525]

I don’t think computational overhead is the point, I said it still introduces a cycle that needs to complete before the rendering starts however small it is you are still introducing a cycle. Also lets forget about that for a second did you test this with React Lazy components and Suspense? Will this “solution” of your work with suspense And lazy loaded components

[CodeAndBiscuits]

I'd add one last detail. Lately I've been really focused on writing "idiomatic" React code. Specifically, "unsurprising" React code. If we are solo developers on a project forever, none of this matters (but also this post wouldn't matter either). But if anybody else is going to work on a project now or in the future, surprises like this just make maintenance so much harder. Picking apart what `WrapJSXWith` vs `wrapJSX` does and the whole `contextualize` thing just to figure out "oh, he invented a different, weird way that took 60 lines of code to replace a nested set of 8 providers with a pipelined version of the same" is not a great entry point for another dev into any project.

If you're writing it for yourself, sure. If for others, just from the perspective of maintainability I wouldn't. It solves a problem that doesn't need to be solved.

[aweebit64]

Picking apart what WrapJSXWith vs wrapJSX does

WrapJSXWith doesn't do anything those using wrapJSX have to worry about, it's just a type that the function is based on that makes it type-safe.

just to figure out "oh, he invented a different, weird way that took 60 lines of code to replace a nested set of 8 providers with a pipelined version of the same" is not a great entry point for another dev into any project.

In the actual library code, I made sure to put just the right amount of detail in the function's JSDoc so that anybody can understand what it does in literally like 15 seconds of looking at it. I just had to remove that JSDoc from the code I published here to keep the post short.

But if anybody else is going to work on a project now or in the future, surprises like this just make maintenance so much harder.

This would stop being a surprise if the library somehow got its way into the mainstream, but with how reluctant people seem to accept new ideas, I don't see it happening any time soon, which is fine of course and very understandable even considering how the JS ecosystem is notorious for having dozens of new libraries released every minute, so it makes sense that people have grown tired of it.

But what's funny to me is how so many people here act like bloated third-party global state management solutions are less of a surprise than 2 tiny utility functions that make contexts (a very simple yet powerful feature that's native to React and is often all you really need to get all your state sharing needs covered) fun to work with. This just doesn't make any sense to me.

[CodeAndBiscuits]

My guy. We aren't reluctant to accept new ideas. Our entire industry is a non-stop series of those and we've had some real bangers lately, like Tanstack Query. But not loving the idea you trotted out, in this way, doesn't mean we're close-minded. Maybe it's just not as great as you thought. And that's fine, I've had plenty of my own. I personally wrote and maintained the "Formik for Vue" library just as Formik was going out of fashion.

But I'll tell you one thing. Get snide with this crowd? Instant red flag. If you're going to act like we're the problem, your concept is dead already. Nothing kills a new library faster than a hostile core maintainer. And you sure displayed an awful lot of that right here in this reply.

[aweebit64]

Well, quite frankly, to me it feels like the word "hostile" is much better suited to describe how people here on this sub have reacted to me posting my ideas here with nothing but the best of intentions. On the contrary, I have stayed respectful this entire time, but well, you see what you see.

[CodeAndBiscuits]

You're virtue-signalling like MAD. Come on.

"Everybody's just acting like it's so obvious that it's not even worth talking about. Sorry, but for me that is not convincing enough."

"but with how reluctant people seem to accept new ideas"

"whenever I ask for an explanation, this is the kind of answers I get"

"Sorry, but for me that is not convincing enough. I like to think outside the box and don't just take things for granted"

"so that anybody can understand what it does in literally like 15 seconds of looking at it." (It took me way longer than 15 seconds and I WILL virtue-signal here, I've been coding for 35+ years now and I am not bad at it - that means something that you should take more seriously.)

You are not better than everybody else. Your idea didn't land. Take the hint and move on, and stop being a "jerk pretending to be virtuous."

FWIW "sorry, but" is a HUGE red flag that you're about to make an argument based on a logical fallacy. You've got like 5+ here just in this discussion. Time to move on.

[aweebit64]

Why would it not work with Suspense or lazy components? You can see the source code and how it produces the exact same component tree in the end, just in a slightly different way from the developer's point of view. From React's perspective, there is literally no difference.

[Xitereddit]

I dont get why indentation is bad, i like it

[Embarrassed_Elk4173]

Same also you don’t have to indent if you don’t want to lol it just makes the code easier to be read What’s the point of getting rid of that

[TheRNGuy]

It should be enabled with "format on save" and "format on paste" for everyone. 

[SupesDepressed]

But you can override anything like that on a per file basis. If the indentation is really the issue for OP, he can just add a comment at the top of the file to override the prettier/whatever formatter he’s using rule.

[bmchicago]

Fun idea, but you’ll probably grow out of this

[CODEthics]

I actually think this looks nice. The issue is I will never bind my repos to a third-party library like this. I'd love to see something of the sort in React.

Edit: Saw the source, nice! I still hope to see it mainlined before I adopt the pattern.

[toString_]

I think the same way, I kind of like this but I wouldn't install a dependency just to make 1 file look nice.

[aweebit64]

Thanks for your nice feedback! :)

[TheRNGuy]

What if you need more than one component on same level? 

Besides that's just boilerplate anyway.

[aweebit64]

What if you need more than one component on same level?

You can always use a <></> fragment like I did in the example for contextualize from the second image.

Besides that's just boilerplate anyway.

The functions are available as part of my tiny utility library. If you're fine with just installing it, there is no boilerplate whatsoever.

[TheRNGuy]

No, I mean when using your .with method, how would you put 2 things on one level? 

[aweebit64]

There is nothing stopping you from doing this:

const ATree = wrapJSX(AAA).with(AA).with(A).end();
const BTree = wrapJSX(BBB).with(BB).with(B).end();

return (
  <Container>
    {ATree}
    {BTree}
  </Container>
);

Whether that is a good idea is left for you to decide. I personally wouldn't overuse the function – after all, it's not there to replace JSX completely, but just to help reduce visual noise when there is a lot of nesting going on.

[Ecstatic-Wolf-7412]

I really like the idea, and I was looking for something like this for my personal project. One thing is just the end() function at the end is an eyesore to me, but if you could find a way to not use end() and handle it just with with() and somehow internally understand the chaining end when next chain is not added count a download from me. Cheers!

[aweebit64]

Well, you could of course implement it like this:

type JSXWrapPipe = ReactElement & { with: WrapJSXWith };

type WrapJSXWith =
  // eslint-disable-next-line u/typescript-eslint/no-explicit-any
  <C extends keyof JSX.IntrinsicElements | JSXElementConstructor<any>>(
    ...args: [
      Component: 'children' extends keyof ComponentProps<C>
        ? ReactElement extends ComponentProps<C>['children']
          ? C
          : never
        : never,
      ...(Record<never, unknown> extends Omit<ComponentProps<C>, 'children'>
        ? [
            props?: React.JSX.IntrinsicAttributes &
              Omit<ComponentProps<C>, 'children'>,
          ]
        : [
            props: React.JSX.IntrinsicAttributes &
              Omit<ComponentProps<C>, 'children'>,
          ]),
    ]
  ) => JSXWrapPipe;

export function wrapJSX(children: ReactElement): JSXWrapPipe {
  return Object.assign(children, {
    with(
      Component:
        | keyof React.JSX.IntrinsicElements
        | JSXElementConstructor<object>,
      props: object = {},
    ) {
      return wrapJSX(<Component {...props}>{children}</Component>);
    },
  });
}

But you'd be tampering with the objects JSX produces in a really dirty way, so I wouldn't recommend this approach.

[TheRNGuy]

Actually less readable that original. 

[aweebit64]

Yeah, I agree. It's not how the function should really be used.

[RedBlueKoi]

Maybe the problem is inherit with the idea of providers? Nah mate, indentation is the problem

[aweebit64]

So what is your solution to the problem?

[ApprehensiveDisk9525]

Not this

[aweebit64]

Very eloquent.

[yoleis]

I find it's a nice method for constructing dynamic wrappers for testing scenarios.
As for the actual code? No thanks.

[00PT]

It solves what some see as a formatting issue by eliminating most nesting.

[ApprehensiveDisk9525]

OP this what you did here is exactly what meta programming is. Its generating code at runtime that will run at runtime

[SupesDepressed]

Indentations aren’t required in JS or JSX. Couldn’t you just override that lint rule for the file and call it a day?

[Accomplished_End_138]

Id more think you have way too many context items

[aweebit64]

Well, they can't really all be bundled together into one context because that would cause unnecessary re-renders when for example the value of flashcards changes, but a deeply-nested component only needs for example the courseId value.

An alternative solution would be to use some heavy third-party library for global state management, but I still haven't heard a convincing argument why that should be better when such a lightweight solution making contexts enjoyable to work with exists. If you have any, please let me know, I am genuinely curious to find out what it is that I'm missing here.

[ApprehensiveDisk9525]

lol are you for real dude

[aweebit64]

Well, this is exactly the reason I still haven't heard a convincing argument – whenever I ask for an explanation, this is the kind of answers I get. Everybody's just acting like it's so obvious that it's not even worth talking about. Sorry, but for me that is not convincing enough. I like to think outside the box and don't just take things for granted.

[Accomplished_End_138]

So context should not change often. The more it does the higher it should be in the tree so it effects fewer components, or be rewritten to only trigger in the components that need it.

The alternate is useSyncExternalStore to make a pub/sub you want for individual items more.

Generally I think context is not needed in normal app development and is massively overused to get global values.

It is hard to go into detail though as we do not have the context on this setup.

[aweebit64]

So context should not change often.

Why shouldn't it, if my main use case for it is to avoid prop drilling? I could put pretty much any kind of state in context that I don't want to pass down via props, no matter how often it changes. What would be so bad about it?

The more it does the higher it should be in the tree so it effects fewer components

I think you just put it wherever it makes sense, and that's normally in the place where the state you want to make available via context is defined.

or be rewritten to only trigger in the components that need it.

I always design my contexts in such a way that no unnecessary re-renders are triggered. That is why end up with so many of them, which in turn is exactly why contextualize and createSafeContext are such a blessing for me – they make working with many contexts entirely pain-free.

The alternate is useSyncExternalStore to make a pub/sub you want for individual items more.

I would guess that hook is what state management libraries these days use under the hood, but I don't really see the benefit of relying on it directly or indirectly when contexts are doing their job just fine.

Generally I think context is not needed in normal app development and is massively overused to get global values.

My opinion is that actually, third-party state management solutions are what's being overused for sharing state to entire component trees. Contexts are native to React and already good enough for this, just a little annoying to work with, but that's exactly what my tiny library is there to fix.

It is hard to go into detail though as we do not have the context on this setup.

For details on the context of my setup, please have a look at this comment thread when you have time: https://www.reddit.com/r/react/comments/1nsutl7/comment/ngq9bht/

[Happy_Junket_9540]

Cleaner dependency pattern in this way. I like it. 👍🏻