Packaging JavaScript based plug and play application - javascript

I am trying to build a plug and play web based application that I should be able to integrate with multiple other web applications (which are developed using AngalurJS\ ExtJS\ ReactJS etc). On click of a button, I should be able to launch a sliding menu. On this menu, I want to add Twitter like functionality. On the first half of the menu we will have a textbox (with features like autocomplete & hash tags). The second half with show a gird which will show already posted messages. The panel will be responsible to get and post data to server.
The challenge is, I want to add this functionality to multiple other web applications with minimum configuration\changes. The consuming web applications should be able use this plugin with ease. Certain challenges I see is bootstrap does not play well with ExtJs framework & I may face similar issues with other JavaScript frameworks.
Questions:
How can I package this application? It has a panel with third party plugins (for autocomplete & other features), CSS & JavaScript. I can use web pack or Browserify but I want to keep the solution clean & don't want to add unnecessary dependency.
The consumers should be able to consume the bundle\package with ease & just by adding some references (like my bundle, css file, jquery, bootstrap).
I think, I can get the desired result with a simple ReactJs app, which I can bundle using web pack. But this will introduce other dependency. I want to keep the web application lite and simple.

I can use web pack or Browserify but I want to keep the solution clean & don't want to add unnecessary dependency.
I don't understand the problem. Using webpack or browserfy will only add devDependencies. You won't ship it. You package won't depend on it.
You won't be able to avoid using a bundler if you want to bundle it.
The consumers should be able to consume the bundle\package with ease & just by adding some references (like my bundle, css file, jquery, bootstrap).
If you distribute it via npm (de facto standard in JS), they just regularly import the resources with the correct path (e.g. node_modules/package/styles.css).
In npm you could also declare your peerDependencies (you mention jquery, bootstrap).

1. How can I package this application?
You should minify all your HTML using a build tool like grunt or gulp
If you want to keep the count of different files low, you can merge all your CSS, HTML and maybe even Images (base64 encoded) into your module.js. Ideally you could end up with only delivering a single file.
2. The consumers should be able to consume the bundle\package with ease & just by adding some references.
In that case they just need to include the script, like:
<script src="app-module.js"></script>
If you are able to use EcmaScript 2015, you might consider to package your plug-and-play app into a ES6 Module. Define your module.js simply as:
export var myNumber = 333
export function myFunction() {
...
}
And on the site, which is consuming your app, you simply add a dependency using the import keyword:
import * as service from 'module'
console.log(service.myNumber) // 333
Read more about ES6 Modules.

Related

CreateReactApp: embed end-user plugin at runtime

We have a React application created/deployed using CreateReactApp.
This application is able to display some widgets. We've predefined types of widgets deployed with our own application. We'd like the end-users of our application to be able to develop their own type of widgets - using a dev tool like Webstorm/VisualStudio - and deploy them into our application.
Our application needs to provide a public API and a plugin dev library
We want the plugins to be able to use the libraries our application is using (e.g. React, material-ui…)
We need a way to "load" end-user code that is registering new widget types using our public API.
Can we do that using CreateReactApp or do we need to eject?
What are the best practices for doing this?
I have more a suggestion than an answer, a best practice for that can depend on the structure of your current project, so I don't think there's a right answer. I wrote a small proof-of-concept, feel free to fork and use that, if it helps: https://github.com/anderick/react-dynamic-components.
Our application needs to provide a public API and a plugin dev library
To solve this you can create a folder structure to let users upload their component projects.
You need a name or id to link this new uploaded project so you can load it later.
We want the plugins to be able to use the libraries our application is using (e.g. React, material-ui…)
If the use is only allowed to use the libraries you already have, you don't need to worry about their package.json.
In case you want to allow users to use their own libs, it adds some complexity on how to process this during runtime.
We need a way to "load" end-user code that is registering new widget types using our public API.
You can use create-react-app in this approach, but you may need a good definition of an entry point (in my example project, I'm using Index.js as the file I'll use as the main component of the project), or some kind of descriptor(maybe extending package.json) so you can read from your application to understand how to load the component. I'd go with the first approach, convention over configuration is more simple, and you can expand from that with a descriptor later.
by ejecting you can customize anything you want but you've to configure and maintain it by yourself, I think going through CreateReactApp also a good idea based on your criteria. I hope this article may help you out.
Thank You!
MSS-

Android and Web App sharing Kotlin code

One of the major “selling” points of Kotlin appears to be its ability to compile both to JVM or Android and to JavaScript for the web. To make use of this, it should be possible to have a code base where some files are shared between an Android App and a browser Web App.
However, so far I found little details on how such a thing would be set up, in particularly when working with Android Studio and its underlying Gradle setup, starting from a a run of the Android Studio New Project Wizard. I don't mind if I can only build the Web App on the command line, but I'd like to maintain the Android debugging hookups that Android Studio provides. So far I know very little about Gradle and typical idioms for its use.
I'm sure that I'm not the first person to have this idea, so I'd like to know some best practices on how to set this up. Questions that come to my mind include the following:
Do I mix the kotlin2js and the kotlin-android plugin in a single build file, or do I need to have multiple build files (perhaps I should say “modules” or “projects” except I don't know which)?
If I have multiple build files, should that be two (one Android one Web) or three (one more for shared things)?
If it is two build files, how do I reference the shared sources?
If it is three build files, which plugin(s) do I use for the shared one?
Do I need to split my sources over three different source trees? Are there any conventions how these should be called?
Do I need to split my classes into three groups of packages, or can code for different targets coexist in the same package?
What configuration settings do I need to tweak to make the IDE aware of the layout of my project?
I've read the following relevant documentation, among other:
https://kotlinlang.org/docs/reference/using-gradle.html
https://docs.gradle.org/current/userguide/intro_multi_project_builds.html
https://docs.gradle.org/current/userguide/composite_builds.html
https://kotlinlang.org/docs/tutorials/kotlin-android.html
I would recommend using IDEA wizard to create a simple multiplatfrom project for you (File -> New -> Project -> Kotlin -> Kotlin (Multiplatform - experimental) ). Community edition should suffice.
Answering your questions:
You don't mix plugins. You create a separate module for your common code and use 'kotlin-platform-common' plugin for it.
Three modules, special plugin 'kotlin-platform-common'
Use common sense for source splitting. Put whatever you want/able to reuse in the common code. Put platform-specific code in platform modules.
No package restrictions. You can put everything in the same package if you so desire =)
Pretty sure it should just work. If not, try re-importing.

Angular app, Inside an Asp.Net Core Project, pros & cons

I would like to create a Single Page Web App with Angular but I couldn't decide to project type.
(Just generated files by tools like angular-cli or that generated files inside an Asp.Net Core Project)
I got some question.
What are the advantages and disadvantages of building angular app on ASP.NET Core Project?
Which cases I should prefer to locate angular app inside a ASP.NET Core Project?
I'd like to take a stab at this. I'll agree that the answer is on some part opinion based though.
I have just been comparing the two versions for a new project that I am involved in.
First some facts
The Angular project created inside of the ASP.Net core application is in no way dependant on the .Net code. You can navigate to the directory and type ng serve and run it by itself.
You can copy the angular code to another directory or repo and host it by itself if you for some reason later on decide that you don't want to combine it. All you have to do is copy paste the angular code, and then remove some lines in startup.cs regarding the internal hosting.
The code that gets added inside of the asp net core template is close to the base angular app with a few examples added on.
If you use the login functionality template it implements an oidc client, and an identity server on the back end, (opinion) pretty much the same way I would have done it myself. There is nothing stopping you from rewriting it if you don't like it. At worst it's a good example of how it can be done.
As of today the template is using Angular 8.0.0, you can just change the package.json to get the latest version and run npm install. It works great.
You can still use Visual Studio Code for the Angular parts with a combined project.
Here are when Id choose the different versions (warning opinions ahead).
When to choose the asp.net core angular project.
Small web app with limited functionality.
Small team, probably same person writing angular code as api code.
If you are unsure. You can always split later.
When to choose separate apps.
Big team with deployment builds and automation.
If you want to host angular and asp.net core separately (for reasons such as to achieve maximum performance and load balancing in apps with thousands of visitors).
Separate people coding angular and asp.net
You don't like having it all in same repo and want to split it up.
In a bigger teams and contexts with multiple APIs you will probably have to deal with CORS anyways, but if not you will have to at least think about it for this to work.
If you are unsure, you can always combine it to one app later.

How do you create a meteorJS package with build options for the user?

I'm creating a meteor package for a JS library that contains a number of optional plugins in the main repository. I would like to provide the option for the user to select which library extensions to use, without always including them unnecessarily.
Is this possible with the current build system? If so, where do I begin?
This is not currently supported. In a sense, each package is the "option" you enable through the package system itself. Your current best bet is to just publish packages for each piece and maybe add packages for common build combinations.
Twitter Bootstrap currently does something similar like so:
twbs:bootstrap // normal bootstrap
twbs:bootstrap-noglyph // bootstrap sans glpyhs
Also relevant, some of the (many) pre-packaged stylus packages out there:
stolinski:stylus-multi
cryptoquick:stylus-multi
mquandalle:stylus
I look forward to this answer going stale.

Using Two Customized Versions of Zurb's Foundation Framework in one Web Project

My organization has created an ASP.NET Web Forms template with Foundation 4 baked directly into it. The problem is they didn't include all of the wonderful features available (i.e. the block grid). I'd really like to use the block grid, so what would be the best approach of downloading a customized version of Foundation and having it exist with another customized version in the same project?
I have a folder called App_Assets and this is where they demand we put any custom scripts.
I'm certain this is not the answer you're looking for, but the Zurb Foundation FAQ states:
6. How do I use multiple versions of Foundation?
You don't want to use multiple versions on a single project. If you
are using different versions for different projects, we've got you
covered. You can easily use a system like Bundler to define a version
(with the gem version). This lets you compile your CSS against
whatever version you'd like. If you're using vanilla CSS, you
shouldn't have a problem since you aren't compiling against a gem.
(emphasis mine)
So it doesn't look like there is a (supported) way to do this. Not to say that you won't be able to find a way to make it happen.
I think, there is only one safe way to include foundation 5 in your project.
- include foundation 5 files in your project and set variables $include-html-classes: false;
- use mixins to generate components that you need
for example:
#import "foundation/components/block-grid";
.name-o-your-block-grid{
#mixin block-grid();
}
information about all variables you can find in th source:
https://github.com/zurb/foundation/blob/master/scss/foundation/components/_block-grid.scss

Categories

Resources