MUI Component Dependency Issues

Potentially obvious answer here that I am missing

However I have started down the path of using some Material UI components in a module, and am running into a swath of dependency issues everywhere I go.

First its the node version defined in the default web/ file in the Perspective Component Example and then its certain aspects missing when I try to instantiate components, etc. etc.

Before I try to continue down the rabbit hole of building the correct package.json and file to get this to work, is there an inherent reason this won’t work and is a waste of my time?

Or do I just need to step through the tedious exercise of finding all of the necessary dependencies/version issues and resolving them.

Any help/advice is appreciated!

p.s. I also tried this with @material-ui/core instead of the newer @mui/material and have seen similar issues.

I think I’d need to hear more about the dependency issues you’re talking about to offer a more exact answer, but to start:

There’s no technical reason that you can’t use material ui. It’s a pretty heavy library, and if your users will ever have iffy connectivity or under-powered devices, I’m not sure it’s a good idea, but there’s no technical blocker as far as I am aware. It’ll just take a bit longer for the project to load.

There’s no question that perspective component authoring is a bit of a dark art due to the mixing of different technologies. So let me break things down a bit and see if it helps. At the end of the day, only a few things are absolute requirements for making a simple perspective component module:

  1. You create a properly structured ignition module, using the gradle (or maven) plugin
  2. Your module contains (at minimum) a javascript file that properly implements a React component and a ComponentMeta that get exported to the window
  3. You register your components with the appropriate ComponentRegistrys, each registration providing info about the component, and specifying the BrowserResources (e.g. - your js file)

In theory, this could be done 100% without nodejs, webpack, typescript or anything else.

When loading a project in a browser, perspective does little more than evaluate which components are involved in a project, and then build a set of all the BrowserResources that the project needs in order to operate. The perspective runtime loads those resources into the page, and then starts executing the project.

In the example project, we use webpack to bundle our js, but that’s not a requirement. We also use Typescript, as we’re big fans of static types, but that too is more of a suggested practice than a requirement. Ultimately the choice of tooling is up to you. If you use a bundler, you’ll want to make sure you aren’t bundling a bunch of things that are already provided by the page at runtime, including things like react, react-dom, perspective-client, etc, but that’s really the only major caveat (see the excludes in the webpack.config.js).

Dependency wrangling is an annoying pain that is an unavoidable part of working in the front end world. Unfortunately, there’s no quick fix there - front-end dependency management is a mess, and we share many of the same struggles. We’re evaluating things like Yarn’s PlugNPlay system to stabilize dependencies more as the product grows, but there’s really no great answer to offer at this point.

I will say, the version of node you build with doesn’t generally matter (plays no role at runtime - we don’t use nodejs at all in the product), as long as the emitted js is appropriate and runnable in the target browsers.

I do think there’s room to try and build a better system for integrating front end tools with java build processes, and that’s something I’m going to be looking at in the coming months, but I don’t have anything to share right now.

Anyway, not sure if this helps much, but if you have some specific issues, feel free to let us know and we’ll see if we can help you move forward with the project. But in the end, you are just trying to get a js file that can be added to your jar as a resource - how that js file gets built is up to you.


I appreciate the detailed response, you always kill it with the super helpful page long answer. lol

I definitely think I was getting lost in the sauce of the details around the IA specific implementation in the examples, and not what is needed to add a component.

I think a good next step on my part is trying to register my basic components through normal js so that I can understand the bare minimum needed for the module itself. Then worry about my own implementations after that.

Maybe that will help define a bit of a “Getting started” to outline how to integrate the java side and the web side for Perspective.

I like the idea of an ‘absolute bare minimum’ example. I can’t commit to getting it done in the immediate future, but I’ve made an issue on the example repo as a reminder.

1 Like

i mean the examples are already quite minimal, maybe a bit to many subfolders xd

To someone who barely understands the Java side, and doesn’t really understand the web side very much

It’s pretty overwhelming at first to try and mentally break down what is “generic ignition module” and what is “web functionality” and why is “web implementation detail”

I definitely was getting lost in the Implementation details around the web example as I was trying to understand what all was going on

I’m not sure there’s an answer for this other than diving in.

1 Like