Angular Universal inside Nashorn?
Just what a thought could come up to my mind?
This is just a small internal hypothetical discussion about refactoring The Console to use Angular 2. Basically what the hell, then why and how to use that to benefit The Console.
First of all, the slide says “Universal on Java”. Universal is…
So, “Nashorn and Universal” idea seems to be just a bridge between Angular2 on the frontend and pre-rendering when Java (instead of NodeJS) is on the backend.
In The Console? Why?
However, why just a bridge? And why not using that in a more useful way?
Currently The Console is not a big thing, really. But I try to think of even the smallest things about making The Console benefit from having Angular 2 inside.
The application doesn’t need data binding that much. But how about reactivity? I’ve already seen a need of that but on the Java side (state management) rather than in Console Output (the view).
But there are some ideas that would benefit from declarative approach (I’m not avoiding the “reactive” word). But first, it’s best to remember a single statement:
Data binding > DOM manipulation
of course data binding constructed with event streaming which brings in a reactive collections like ReactiveJS or Collections in Meteor. You can both listen to them and modify them.
1. Play with collections, not the DOM
So, instead of manually creating
2. Keeping logs of the software loading
Next benefit is about deferring the data and log stream to a new tab. If logs come in before a first tab is created, then I have to cache it. If those would be in some collection then I could just bind them. And if the first tab is deleted, then another tab is set as default - those logs could easily come up at the top of new default tab when implemented with data binding.
It’s not undoable right now, but it would be much cleaner by simply putting some *ngIf=“tab.isDefault” template directive.
There’s more. It’s a “PUSH vs PULL” situation. Pushing content reduces CPU cycles and is as reactive as possible - in the meaning, it reduces the delay between new data and reaction to a minimum. Especially, when compared to interval pulling.
This one would be much easier using Angular than it is now. Simply putting a filter as a pipe for the *ngFor directive. Currently, I would have to write a lot more Java code.
5. Dependency Injection
Injecting Services instead of Globals as it is now? Does this looks like a true need? Would I even need them in Console Output? Well, it depends. If most of the logic code would be inside WebView… why would I need Java Nashorn then?
6. Improved Testability
Now that. THAT. This one is what beats the rest. Declarative approach and single tick of Change Detection in Angular engine would be more easy to test when the only test input data would be a collection of entries. Currently, I would need to call some methods to add those entries. And what if some entries will change indepedently of collection?
That makes me to think further about the architecture, regardless of using Angular or not.
7. Reactive Pictures -> Injecting Behaviours
At first I thought about a simple feature like “Reactive Pictures”. If I were to display a picture inside the WebView, i.e. after invoking some command, I may like to display it big but when more content shows up - the picture could shrink.
This is an idea that can be done in multiple ways. However, this behaviour could be easily scripted and injected. So Reactive Picture brings an idea of injecting scripts to behaviours inside the WebView.
However, I will benefit much more from taking the reactive approach than rewriting whole application right now. And talking about Reactiveness in Java, there is RxJava which I’m going to consider of using in The Console in near future.