I’m rewriting a quite complex ionic 1 project to ionic 3 and i’m facing quite difficult issue -
Small part of the app is fetching some html content (including forms) from the server and these were compiled in the i1 app on the runtime (including ionic and custom components/directives) . I am trying to find a solution how to handle this in ionic 3.
One of the options is to disable aot ( build with --dev) and use ComponentOutlet , but i’m afraid this might affect the overall perfomance of the app, and i’m aware that it’s not a good practice in general… Another option would be to move the content into InAppBrowser and serve it from the server, but again this doesn’t feel right…
Are there any other possibilities, like using JIT compiling only for small part of the app and have the rest precompiled?
Client insists on having the content dynamic to be able to control it without releasing new app versions (it changes quite frequently)
There will be no support for this, at all, in Ionic 4. So the client needs to know you’re being required to write an app that literally cannot be supported long term. There might be a way to do something with bubble gum in Ionic 3, but Ionic 4 is coming soon, so you have to decide how critical that is for you.
One possible option is to explore getting the client a paid membership in Ionic. The update features provided might be worth it.
If the container stays the same and only the content changes, that’s different. (Example: container is a list, and the items in the list change.) But other than that, the whole purpose of AOT is to sacrifice runtime flexibility for speed.
Thanks @rapropos, i was actually looking at that post while i was searching for a solution before writing this post.
What is the format you are getting the dynamic content from the server? I’m not familiar with markdown, but i assume this will not work with some more sophisticated elements like forms/inputs etc. , or it will require extensive work to achieve the functionality…
I guess that involves some subjective judgments, but I think forms could definitely be done, and I would argue that it would be both easier and more futureproof than putting effort into trying to subvert Angular’s strong desire to have templates be available at compile time.
Fundamentally, I would try to model your “dynamic forms” as heterogeneous lists of elements - labels, inputs, checkboxes - all the elements we have in HTML forms, and then iterate across them using static components. Here is another thread discussing the strategy with a different example.
this was exactly what i had in mind by writing a component to construct the content. It will require a breakdown of all the existing server side templates into some parseable format (possibly JSON) , but will be probably worth it in the long run.
Thank’s a lot for your insights, much appreciated!
Eh, now that you press me, it might not be exactly what the OP meant by “dynamically.” So my post might have been wrong. I don’t see any reason the @rapropos block strategy would stop working. But I think it’s more than just iOS/Android. That’s the specific example, but it sounds as though all style variables will be completely fixed. So the direction of motion is away from runtime component creation, and toward compile-time component creation. (It was that way before of course, but even more now.)