I have new challange to solve. We would like to create many application with same JS code and base on parameter load different theme and maybe do some extra things for specified value. This I guess is not a problem by adding a parameter at build process and just check it while render.
Question is how to deal with this on native code. I was thinking about copy&paste ios/andoroid code and change all required parameters, name etc, but it sounds like not best approach. Do anyone have idea how to deal with this problem ?
Thanks in advance for help.
I’d suggest you to create a component library that exports shared components for reusability.
For theming you could use the theming library that distributes a theme object in the context including subscriptions to changes. https://www.npmjs.com/package/theming
Libraries like styled-components and glamorous-native already have this built into them.
One thing to note is that you shouldn’t forget to use peerDependencies while pulling all reused dependencies into devDependencies so that you won’t end up with duplicated packages in any case.
Related
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-
I made some SPA using vuejs-templates/webpack and that's ok. But now I am developing a website, almost everything is static, so there's no need to be a SPA. I already made the pure html/css layout.
Now I will make some pages with forms and dynamic content, I would like to use vue components inside these pages.
Tell me which of this ideas is the best or give me a better option:
Multiple entries in webpack: I don't know very well how to do it, but I guess I can create a webpack project by scratch and render multiple entries that I include in the pages I want.
Use browserify: I didn't want to do this, but sounds like a good option... I could use vueify to render *.vue components
Use Nuxt: I never tried, but seems a good option too, I could make a "SPA" with SSR.
Tell me if you have another idea.
Thank you
Don't rule out just referencing Vue as a script file. No bundle, no compilation step. You lose single file components, but you can get something very like them by using js template literals. If your needs are simple and you don't want to impact on the rest of the site, this could be a fine solution.
I'm working on a JS library that relies heavily on D3 (and to some extent, lodash). I've modularized it, have bower_components for the external library dependencies and node and gulp for the build/concatenation/uglifying process. So I'm covered from the development standpoint (no need for require.js).
However, in order to let other people use my library, they need to have both d3 and loadash loaded. I don't want to bloat their loading but at the same time I want to make things easy for everyone. Should I just concatenate my dependencies along with my .min.js and have that be a release? What are the best practices?
BTW, my current versions of lodash and d3 clock in at 52k and 148k respectively. Thanks!
I seems interesting to embed dependencies in your own library to offer customers an easier way to integrate your component, but think about that:
They may use another component requiring a more up-to-date D3 (you embedded)
For performance reason at load time, your customer may want to use D3 (or other embedded libraries) using the official CDN (better access and downloading time)
You will have to carry about updating your component each time one of your dependency is fixed.
For other more reason you could find by yourself, it is not a good practice to embed dependencies inside your component unless you plan to manage a full support of it.
I'm using a nice framework for Adobe ExtendScript called Extendables. I forked the project here: https://github.com/daluu/Extendables
A problem though is that in some ways using the framework is worse than not because the framework extends javascript objects with more functionality. And on an initial review of the code files, they seem rather interdependent such that it will take some work to uncouple the strict dependencies to make it optional/configurable to load only what you need and skip the rest in case of issues with particular features (i.e. you can just not load/include what you don't use - I don't think that's currently possible, although I might be mistaken). See the issue tracker in my project for details but in general the issues encountered using the full framework is failure of try/catch blocks and object iteration includes unintented properties.
For me, I'd just like at a minimum to make all functionality optional and just load the logger and Jasmine test framework as those are the only two feature/modules that I really use with Extendables. I don't care for the extensions to strings, files, object, arrays, etc.
As I'm a novice in javascript/ExtendScript, and this is not a trivially simple javascript framework, I could use suggestions on how to decouple the dependencies so that every module (baring it's dependendencies) can be optionally loaded, and where there are dependencies we can group into sets as in you can load or not load this set of features.
Sorry that I can't include code snippets as its too much to post, you can find it in my Github fork.
Not sure if this is best StackExchange site to post but starting here.
You should be able to extract the log module from this file:
https://github.com/daluu/Extendables/blob/master/core-packages/logging/lib/index.jsx
Try to use it like this (not tested):
#include "core-packages/logging/lib/index.jsx"
Log.debug("Log this");
You might need to adjust some things in there e.g. Folder.extendables does not exist in ExtendScript. Also exports.Log at the end will throw an error.
I am using requirejs so that I don't have every single script in the head tag for every page. The main motive behind switching to use requirejs is that we have plugins such as CodeMirror, with like 15 plugins to extend that too.
What I want to avoid is having for example:
require(["cm", "cmxml", "cmcss", "cmcodefold", "cmfoldgutter", "cmbracefold", "cmcommentfold" ....], fn);
I'd like to have this as just require(["cm"], fn); and automatically include all of the plugins with this. I'd also like to keep the plugins separate, so combining all the files into CodeMirror.js is not an option.
What I am wondering, before I go creating my own functions or modifying 3rd party code for this, is whether requirejs allows this kind of loading in any case? I have looked at the docs a lot and can't find anything, but that doesn't mean I haven't missed it or that it isn't documented. Thanks in advance.
Well I've managed to get this working using a shim for a script called cminit.js - the deps array simply lists all of the plugins for CodeMirror, which in turn have a dependency on CodeMirror which in turn has a dependency on jQuery. So one call to require for cminit.js automagically means that jQuery exists.
It works, but I'm not sure how much of this is best practice. Feel free to comment if you have a better way to do this.