React error-message of the day

This just in:

Failed context type: Invalid context `paneset` of type `Paneset` supplied to `Paneset`, expected instance of `Paneset`.

Oh, the joys of front-end development!

(My best guess: I have two slightly different version of stripes-components library that provides the <Paneset> component in my application, and somehow I’ve got hold of one from the wrong instance.)


8 responses to “React error-message of the day

  1. Maarten Daalder

    I never would have guessed that JavaScript would one day reach JBoss EAP 4.x/5.x level of error messages when both the deployed application and the application server had the (exact) same jar included.

    So only 9 years difference now! :D

  2. It’s so, so, disappointing to still be running into such Dependency Hell problems in 2017.

    (Thinks: I wonder why this never happens in Perl.)

  3. Maarten Daalder

    I always associated Perl with being able to convert between types seemlessly (ints to string and vice versa), so perhaps that’s the reason why it never was a problem? I must admit I was never that proficient in Perl when I programmed in it.

    Or perhaps in Perl one type overwrote the other?

    One advantage in Java is that with Maven you know you will only get a single version of a library (unless you get ‘groovy’ and ‘groovy-all’ like mismatches).

  4. Ah, but this is a JavaScript problem, not Java!

  5. Maarten Daalder

    Yes, but I was noting on the similarity of the problem you had in Javascript with ones I had 9 years ago with Java. Since 9 years with the introduction of JBoss EAP 6.x they have effectively disappeared (and other OSGi-like containers).

  6. Coincidentally I just spent a couple of days dealing with dependencies upgrading a pretty good-sized project to React 16. To give you an idea, the node_modules directory is 773M. There was definitely some dependency hell involved. I seem to have it sorted, but not very much fun. Dependency resolution is hard.

    I think part of the reason this bites a bit more in JS than on some other platforms is the way the npm ecosystem works. Lots of little libraries that change frequently… I’m kind of surprised it works as well as it does, tbh.

  7. “I’m kind of surprised it works as well as it does” is typically the most ringing endorsement one hears of such dependency ecosystems. Once again, I wonder why it never seems to be a problem in the Perl world. I can’t see an obvious difference that would make it so. Perhaps front-end JS is just moving unprecedentedly fast.

  8. I think that’s part of it (the unprecedentedly fast bit.) It’s also that the npm ecosystem has so many small packages and that the dependencies and sub-dependencies are so highly connected.

    I don’t recall there being a great number of CPAN packages that relied on other CPAN packages named things like “is-number” (which pretty much does what it says on the tin,) and I don’t recall there being too many CPAN packages named thing like “is-number” that were on version 3.0.0, or had 26,402,258 downloads in the last month.

    Thinking of Python, which I have much more and much more recent experience with… well, Python comes with a pretty large and pretty stable standard library. JS… less so. Even so, Python dependencies can sometimes get kind of hectic, but it’s not usually as big a deal.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.