I'm starting a project where I will be making a suite of applications. Each application will be its own SPA, hosted on its own domains.
However, each application should use the same layout - nav bar up-top and pull out drawer on the left side. All the text and menu options should be handled dynamically (depending on the spa using it). What is the best way to go about this? How can I make a single layout component that can be used across multiple applications?
Please keep in mind that each SPA should have the ability to be developed independently - one might be ReactJS another might be VueJs or Angular.
Also, my employer does not want to use a micro frontend framework. I was hoping someone that is more experienced can help me out here and throw some ideas my way. Would I make this an npm package?
I would like to use strapi.io as my content manager, and I want to build the layout in quasar.js (but maybe I should build my own with no framework so each spa does not have too many dependencies IDK).
Related
I'm working on two webapps built with Nuxtjs which are like e-learning apps. One app (App1) acts as a CMS from which a teacher prepares courses, and in and the other app (App2) is like an end result where a student can go through the content created.
Now I want to implement an instant preview of the App2 in the App1 when content is being built.
So I was wondering what the best approach, that's quick and seamless, is to go about it?
I was thinking of sharing the components in an NPM package between the two apps but the thing is that almost all the pages of the App2 should be used in the App1.
Or loading the App2 in an Iframe in the App 1 but no sure how to instantly show the changes being made in App1?
All ideas given is appreciated in advance.
As I guess you want to create two apps that have common components, and different logic, sharing components via npm package is a really good idea, I think you can also use Layout feature, you can have more than 2 scenes, But that can make the app little bit complex, it depends on how to organize your business logic.
Currently, I need to modularize an app into smaller modules. As far as I've known, modularization is the concept of separating an app into smaller components, which will be developed by a specific team. Finally, these modules will be merged into a complete production. However, my manager wants to review/test these modules as standalone apps. For example, we have authentication module and news module. Normally, user need to authenticate first, then navigate to the Main Screen (which contains News Module). But in my case, we want to test/review News Module without the authentication step as a standalone app.
Through my research, I've found a library for modularization. But i don't know if this library can match the above requirements. Is there a more official way to do this without creating many different repo/npm library for each module? Have any teams faced this kind of modularization before? Thank you in advance!
Good,
My question is really simple. I have a web project made in Vuejs and I would like to know if there is any way to take this project and to mirror it to NativeScript-Vue in some way.
Thanks and best regards!
There isn't an automated way to migrate your app. The templates should be completely rewritten as the mobile world has different UI components and concepts. Your scripts and styles, for the most part, should work the same way. You will need to figure out how to do the routing as the default vue.js router is not supported. You can check the manual routing article fore more information.
I am about to start building a mobile site which is dynamic, working from a lot of dynamic content which must come from the database.
I have already written a REST API for the site which the IOS and Android applications are using to interact with the information.
My question is what would be the absolute best practise for building this site, would it be:
1- Make the mobile classes an extension of the existing site functions
(The downside I see here is that the mobile site would be dependant on the main site library meaning that any bad heat on the main site would also affect the mobile site)
2- Make the mobile site a completely stand alone site running from itself
(The downside I see here is that any change to the main site library will need to be reflected here so in essence we would almost be writing code twice)
3- Make the mobile site run from the REST API and standalone
(The downside i see here is just increased number of HTTP requests for the information rather than communicating with the server directly)
Each one would function normally and there wouldn't really be any problem there, coding is really not too difficult, though if I make it standalone I would need to recreate a lot of the functions from the main site and adapt them for the mobile site which isn't ideal.
Look forward to your comments! Thanks
I would go with 3rd point, but that needs to be architect well.
We will prioritize standalone application after that API, also we can have 2 way communication, any content changed on server it will coordinate with clients to get that updated.
Also I would also suggest go with Bootstrap framework, its an awesome framework and have responsive and adaptive design
I really like the new feature, Web API that's released with MVC4.
I'm currently working on a web application, that I will want to extend it to a mobile application.
What would be the best way of utilizing this feature?
Program it like there's no Web API, and when i'm ready to develop for a mobile application, then use this feature (Copy and paste controller functions then edit the return and error handling value ?
Or should I use Web API from the beginning of the web development. Using javascript to call functions and to handle errros? The problem with this apporach is I'm not too familiar with JS, and the code would not look very clean (the Views)
Any opinion?
Thanks
IMHO the Web API shouldn't be seen as a feature specific to mobile application development. It's a tool allowing you to easily expose RESTful APIs over HTTP. Those APIs could be consumed from desktop applications, web applications, mobile applications, etc ... The interface for each type of application will of course be developed using the specific frameworks and tools for this task (WPF, ASP.NET/MVC, WP7/iOS/Android, ...).
The Web API just allows you to expose your business data and services in an interoperable way so that different clients could consume them.
I would prefer using the second approach.
In the beginning, I also thought the .ajax calls might mess up the Views. (No one likes to add a long <script> section in a View.) But after asking my questions on Stackoverflow, I am glad to find some experts here using some "code-behind" for those javascript.
The practice is:
Create a separate JS folder to store all the "code-behind" js files. (The default Scripts folder only contains the third-party packages like knockout.js, jquery.js and etc)
For each view, generate a .js file, like home.index.js, form.add.js, etc. Just follow a consistent rule. There will be a lot of js files created. The great thing is in MVC4, we can combine all .js files under this folder and generate a minified, combined, single file, and load it only once in the _Layout view.
The way to do it is:
In _Layout view, <head> section:
<script src="#System.Web.Optimization.BundleTable.Bundles.ResolveBundleUrl("~/JavaScripts/js")" type="text/javascript"></script>
In Global.asax, Application_Start, register the bundle:
var bundle = new Bundle("~/JavaScripts/js", new JsMinify());
bundle.AddDirectory("~/JavaScripts", "*.js", true);
BundleTable.Bundles.Add(bundle);
BundleTable.Bundles.EnableDefaultBundles();
//BundleTable.Bundles.RegisterTemplateBundles();
Then you are good to go. The Views are still clean. All the .js files are organized. And no need to import different .js file on each individual view.
Leaning JS is not a problem. As it is probably the only client-side programming language, it is now becoming necessary for us to learn new things. And I feel it is easier since we have jQuery now. It is time to upgrade our knowledge. I am happy and excited about what we can accomplish with these new tools.