Open lukasberanek-tpa opened 1 year ago
Hey! Thank you for the contribution. I wonder if this is the right approach. Maybe we should have a dev mode and a prod mode that ignores warnings?
I'm not sure about the feasibility of a dev mode/prod mode for a library though. I'm not sure we can use process.env.NODE_ENV
in all cases 🤔 (it assumes that people are bundling the lib - which is probably always the case haha)
Unfortunately this won't fix my "problem": I have two tables next to each other with multiple pages that I can click through. A row from one table can be connect to multiple rows in the other table. The problem is that these can be "hidden" in another page of the other table. Therefore I just create the relations in the first table without checking if they are actually visible in the other table.
In that case, maybe we should ignore all warnings by default, and set a isDebug
context with a props on ArcherContainer
once, defaulting to false. That would make more sense :)
It's a breaking change though, but a minor one.
I actually think that the warning is a good indicator for the majority of use cases. Obviously I found one where it's not desired :)
Maybe we have to combine our suggestions by adding
isDebug: props.isDebug ?? process.env.NODE_ENV !== "production"
on the context. This combines both:
isDebug={false}
in the props (like I would do)What do you think?
Pretty self-explanatory: ignore
console.warn
in case the target or source is not found.