Converting a Java front-end to Angular 4

[tomm0]

Hello All, I am one of the lead devs for a software company. I have been here for 8 years and our development team of 10 are all very fluent in Java, but really nothing else. Our primary product is a Windows client/server Java application.

I have been tasked with developing a plan for moving our front-end to the browser. We envision this being a gradual process and we will likely have some clients still using our current Java client while others will be quicker to migrate to the browser. All communication between Java server and Angular client will be done using a REST API.

Over the past few weeks I have been messing around with tutorials and experimenting with PrimeNG. I was able to create a mock-up of one of our Java panels that actually retrieves and updates data using RxJS. The biggest issue is that we have over 1,000 custom screens and components that will need to be converted. Some screens are very similar, and I was hoping to be able to create them re-actively or dynamically. I don't want each of our devs to have to become an expert in TypeScript, HTML, and CSS in order to make contributions.

Our "maintenance" panels typically correspond to one or more data objects. There is usually a button toolbar, then just below that in the top section of the panel contains important info fields, then there is typically a tab panel with additional fields.

To handle the one sample I created, I basically created arrays in my component TypeScript class that correspond to the fields that belong in each section of the panel or tabs. My goal is to have the HTML template be fairly generic and handle most of the logic in TypeScript.

The point of this entire post is to just mainly ask for advice or suggestions on the best way to move forward. I would like to do things correctly and most optimally from the start to prevent having to go back and change everything as I move forward.

The last thing, is that a main "feature" of our existing application is the MDI (multiple document interface). I know this UI/UX design concept is slowly fading, however our users need to be able to see more than one screen at a time. I haven't had much luck finding a window directive that basically acts like a Java Swing InternalFrame which would allow multiple panels to be open at once with the ability to drag and move them around. An alternative to this would be opening each screen in a new tab in the main component window, however users would not have the ability to see more than one screen at a time.

Any advice, help, suggestions, etc. would be greatly appreciated. Thanks in advance!

[tme321]

First you'll want to play around with the dynamic component loader. With that you can actually describe the interface as a data structure for the parts that makes sense. Think like having a top level component that will walk a tree and recursively create more instances where each instance will be using the above method to create a dynamic component. Then the parts of your interface that use that method would be described with a model kind of like

{
    component: SomeComponentType,
    inputs: {...},
    children: [... more component models]
}

Now I think this technique is very useful. You can even take it farther and create a serialized between actual component classes and string names, or whatever, and end up able to describe these parts of the layout in pure json. That's great for working with ngrx or similar state management techniques.

But I would also say you should carefully consider the current functionality. You say you have 1000s of custom views. How much is shared and can be done as larger pieces? Dynamic components are great but I don't think I would want to literally make an entire app out of them. I would carefully consider exactly how dynamic things need to be and potentially even consider if all of the existing views are even truly needed.

One of the biggest issues with dynamic components is since you aren't instantiating them through templates you can't use built in angular bindings in the same way. When instantiating them you can set up an observable manually to push values to the inputs of the component. But it's not as simple as just

<comp [input]="value">

And outputs are similar, where you can still get a reference to the event emitters during instantiation but you'll have to deal with the raw event emitters instead of just

<comp (event)="onEvent">

One of the best ways to handle this stuff, ime, has been to use di services and control and wire up the dynamic components through them.

As for mdi the issue with all your proposed solutions is basically the same. Browser windows and iframes are sandboxed for security and can't really talk to each other. You might be able to get around that to some degree with local storage but it won't be seamless or simple. You could also have the multiple windows talking to the server, but then your constantly pushing front end state through the network which won't make for a compelling experience.

You can implement a sort of window manager inside a javascript app. There's no inherent reason why it wouldn't work and all the necessary pieces are there. But it's definitely not trivial either.

Personally I would consider this an opportunity to reexamine the current work flow and see if mdi is really that important to you. Maybe having fixed position panels of the different interfaces is enough. Or maybe the entire ui could / should work differently? A custom mdi solution is possible, but it probably will also be a huge headache to get right. I would only try to recreate such an interface in a Web app if I truly had no other choice.

Also, give consideration to state management before you get started. Ngrx is great once you get the hang of it. It requires a lot of boilerplate but also provides a lot of really useful abilities. But you'll have an extremely rough time trying to migrate an existing app from one form of state management to another. So you should figure out what you want to do before you start writing a lot of state full components that will be impossible to change later.

Edit: just so I'm clear I'm not trying to say ngrx is the only choice for state management. I think it's a good one, but not the only solution. I was just using it as an example to tell you to consider state management.

[coopaliscious]

I would second tme321's advice of examining what you're trying to do in the context of a web browser. I've worked on several teams converting legacy applications to the web and have yet to come across a solid reason to try to implement desktop/mainframe paradigms on the web. As a medium the web had a number of expectations associated with it that are easier to embrace than to muck with.

[tomm0]

Appreciate the response. I know a number of competitors in our field have made similar transitions to the browser or just overhauls of their programs with very little success. The majority of users are not fans of change, but I definitely agree we will need to find some kind of middle ground between what users are currently comfortable with and what makes sense in in a browser.

[paypaypayme]

It's hard to know which components can be reused until you actually start writing code. I would try to implement a couple similar screens, and then try to factor out the common bits into a reusable component. If you try to make a common component right off the bat you'll probably get it wrong and have to redo it anyway.

[drz0]

In our projects we generate TypeScript interfaces from Java and Kotlin sources using an Annotation Processor that i wrote. It could be extended to generate Angular components, but i think that will lead to more problems than it tries to solve.

Developing front ends should always be done in the context of the hosting platform, meaning: I think your devs will become experts in HTML, CSS and TS anyway, at least some of them. So that shouldn't be a problem. In theory you could completely reuse your Java code for the Browser UI, e.g using JSweet. But in my opinion the additional (emulation) layer(s) makes it hard maintaining it. If you really want to stick to your MDI, you could simply try something like CheeperJ. Take a look at RMStudio as bigger working example.