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-
Related
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.
I am new to Qt/Qml and javascript.
Let's say I have a javascript file which contains a table of parameters. The javascript file is used in Qml and it is located in the application directory. e.g. C:\Program Files\QtApp\the_table.js.
If end customer installed the Qt app, they want to manually edit the javascript file and use it with the installed application. ( No need to recompile the app source code).
How can I make it work?
I have tried to update the javascript file manually, but when I try to open the app again, the "updated entry" in the javascript file is not displayed in the application.
-----------------8<-----------------------
Updates:
Javascript file included in the qml resource will not be editable by
end user without recompiling the app.
Javascript in qml will hold mostly the logic, not the data.
It's better to use the JSON file to store the configuration data that can be modified by the end user.
Qt 5.0 and newer version has support for reading JSON file. QJsonDocument.
It sounds like the flexibility you require should be implemented at application level rather than externally. If it is just a "table of parameters" there are plenty of ways to do it in JS.
Due to implementation details you most likely don't want to bother with, that would be much preferable to updating the actual JS file.
Consider the usage of import Qt.labs.settings 1.0 which will allow you to store and make changes to settings that persist across application runs. That would be marginally easier than parsing config files. That being said, doing so is very much a viable option, you just have to interface QDataStream to QML.
That's the best I can do without knowledge of specific requirements and usage scenario.
OK, after a quick test, it seems that it is possible to import a file from the file system, you just need to:
import "file:///pathToYourExecutable/YourScript.js" as YourScript
Then you can use YourScript in QML. However, I would not recommend using this, as it invites opportunities to mess up with the application. The user shouldn't really be editing any files to make changes, just seems like bad design. Whatever it is that you want to achieve, there is most likely a better way to do it.
Solved by changing to use json file to store the data and then access the json file in QML.
The class to read the json file from the disk is JsonFile class in Qt, check this link:
https://forum.qt.io/topic/39756/qml-and-js-reading-json-file-and-change-content-on-the-go
Background
I have a javascript library that runs on a customers website. This library is a mixture of standard components (error handling, message passing, etc), and per-customer based custom components (specific dom handling routines).
Problem
I am breaking DRY. For each customer, I have the same code duplicated. Since I violate DRY, I am stuck with all the pitfalls: e.g. if I need to make a change to a common component, I have to replicate that change across multiple files.
Desired Solution
I'd like to separate out all the functionality into components, and selectively choose (via build script) the components that get added into the library.
This would be somewhat similar to how Bootstrap allows you to mix and match javascript plugin functionality
Example: CustomerA's library, needs the Base Component, the Comment Component, and a custom handler to parse Google Analytics.
CustomerB's library, needs the Base Component, and a custom handler for their shopping cart experience.
I think I can do this with RequireJS, but is there a more industry standard way to build customized javascript libraries?
I came across Browserify, which allows you to use Nodejs module system to create reusable components, in addition to using NPM node modules.
I need clarity into being able to modularize my JavaScript code that leverages Ext JS. My objective is to create custom classes that extend Ext JS widgets, distribute code among several JavaScript files (.js files).
I have looked into documentation on Ext.Loader but I didn't quite follow the approach to ensure class dependency resolution. My code in a single JavaScript file is working as desired, given that the code sequentialization is as per dependency. But once I break the code in several JavaScript files and want to use in multiple pages, my dependency is in a disarray as all my pages require different classes with varied dependencies.
Considering that I easily achieve code separation and reuse quite easily in regular backend coding, this has baffled me. Please help with inputs. I'm using Ext JS 4.1.1
To enable dependency resolution when creating custom components, use the requires param of Ext.define. It looks like this:
Ext.define("My.custom.Widget", {
alias: "widget.mywidget",
requires: [
"My.custom.TextField",
"My.custom.ComboBox",
"My.custom.Store"
],
constructor: function(config){}
/* ... */
});
For more information, you should read Dynamic Loading and New Class System from the Sencha website. It goes into more detail about how dynamic loading works. It's actually really cool once you get the hang of it.
Almost forgot. You can explicitly call Ext.require to load certain files when you need them. It supports wildcards, aliases and such. There's also Ext.exclude to prevent certain files from loading.
Sencha has some really great guides to help you master the framework.
http://docs.sencha.com/ext-js/4-1/#!/guide
A good one to start with is this one: http://docs.sencha.com/ext-js/4-1/#!/guide/application_architecture Application Architecture. This guide clearly shwos you how to modularize you code and the folder structure the Loader is expecting.
Please have a look at it.
When developing javascript code, what are the best practices for maintaining the code in repositories?
For example, suppose I develop a set of useful functions and put them in a script called "sugar.js". In the code repository I put them in c:/codebase/suger.js.
Now I want to use the script in a web site being developed and I locate it at c:\mywebsite\sugar.js (ready for uploading to a server)
Do I keep a copy of sugar.js? What if I fix sugar.js in one location - it won't be synchronized with the other?
What if I build a second web site that also uses sugar.js? Do I take another copy located at, say, c:\mywebsite2\sugar.js?
If you are using something like visual studio, you can use NuGet for versioning many of the popular javascript frameworks on a per-project basis.
If you are writing in something else, you could try package managers such as npmjs or http://jspkg.com/JSPkg.
If it is your own library, I would recommend setting up source control and having versioned releases as branches or tags, that way you can keep track of everything. Git and GitHub support this type of thing, and you can set it up to have each version as a zipped download.
I would also try to keep each project's javascript files separate, that way any changes won't immediately break every site, just the one you recently updated. This advice could go out the window if you are running hundreds of sites and really just need a CDN.