I have a piece of web software / web app which is predominantly javascript. It uses extJS framework and considerable custom scripts. The global stylesheet, call it main.css, consists of extJS library styles and our own new styles and extJS style overrides. This is all compiled using SASS.
Now, I want to embed the app into a web page. This is being done without an embed wrapper, but actually running the app in the page, including using global styles.
The external content in the page (non-app) is custom design using Bootstrap CSS framework and some jquery elements along with some Bootstrap overrides and some custom styles.
We cannot load Bootstrap as the global CSS, since the styles are significantly different and independent of the app styles and therefore want to avoid clashes.
How may I call the syles for their relevant areas, ensuring we can also do things like version control/update the core frameworks - extJS, bootstrap, jquery etc. easily and avoid clashes between the global styles - effectively treating them as different silos?
I may be misunderstanding a critical piece to this, but since you're using SASS, could you simply use:
#some-custom-area {
#import "path/to/bootstrap-result.css";
}
That is, take the Bootstrap CSS framework and all the custom rules you've written for it (in whatever CSS files those land in after compilation) and import them into your global stylesheet... but wrapped in a #some-custom-area selector. When SASS compiles that, it'll ensure all rules from the Bootstrap side are valid only within #some-custom-area.
Is that viable?
Related
I am new to React and I want to ask: Should I use style-loader or mini-css-extract-plugin when configuring webpack? I am reading that using mini-css-extract-plugin is better for caching purposes and that using style-loader may sometimes lead to FOUC (Flash of Unstyled Content) since the browser may need some slight time to load JS.
its totally upto You.
But when you will work on big projects. Managing the code will be more complicated. so i recomended you to use seperate css file.
if you want to avoid global styling you can also do that in react by using css modules. to learn more about css modules click here
also you can use Styled components to write scss like codes
to learn more about Styled components click here
Thank you
Our Angular 2 app uses the Material Design framework. The app will end up as a locally served (serverless) web app on a piece of embedded software. For performance we have found it imperative to use non-Angular static html in certain situations due to load time for a couple places in the app.
I want our UI/UX programmer to be able to use as many of the md- prefixed components and CSS/JS animations within the static html pages. In other words I want them to be able to code the UI on a static page just as they would code it within an Angular 2 template, or as close to the same as possible.
I would also like changes or any customization that they make to the CSS or JS to be shared between the Angular 2 templates and the static html pages, as they should have the same look and feel and should look like they are part of the same app.
I know there are various ways to implement material design without Angular 2. (bootstrap, polymer, etc.) Does anyone know of a clean way that would make coding seamless between the Angular 2 and non-Angular portions of the web app?
From what I can tell, there are several implementations of material design (https://material.io/guidelines/) for various frameworks available. The following which can be used on a static html page without requiring an all-encompassing framework such as Angular 2:
https://elements.polymer-project.org/elements/paper-material
http://mdbootstrap.com/
http://materializecss.com/
...just to name a few. The one we decided on was the Polymer implementation. This is because the polymer syntax is very similar to the angular one. (both authored by google) Polymer prefixes with 'paper-' instead of 'md-' but otherwise is very similar and we can add both of these prefixes to any overrides in our .scss files which can be shared between the angular templates and the static html files when we need to override the default styles.
Although it is not ideal to manage to separate material design implementations, given that we require static html files for certain pages in our app it is an acceptable trade off.
Still interested in other solutions to this problem if anyone has any other ideas.
I have been making tests with Riot.js, making tags that would let me or another programmer load information from a github user or his repos.
Right now the tag for the user is <github-user-widget></github-user-widget>, and for the repos it is <github-user-repos></github-user-repos>.
I know that Riot.js lets you have css styles for each tag, but in some cases I see I am going to need a unified style for all the tags; giving all the tags the same font or using a grid system would be an example.
If I load a CSS library like Bootstrap or Bulma.io on the index.html I can style my Riot tags in a unified way, but then I would have to use this library for all my application or website.
I imagine being able to post this tag as a module that other people would just import to their applications, without having to change their CSS configuration, just importing, in this case, Riot and the Riot tags.
My question is: Is there a way to use a CSS library to style all my Riot tags or components in a unified way, without having to use that CSS library for all my application?
At this time not really. You can use HTML transclusion / yield and have one master component that all component live inside. That master component can have the shared CSS / JavaScript, but the reality is that this is beyond what Riot should do, and generally a bad idea. I recommend creating a NPM, and Bower package, with the needed dependencies so that others can consume your components. Its fairly standard to have to include a CSS and JavaScript file, plus if they are already using Bootstrap, you really don't want them to be forced into including it twice.
With Shadow DOM, I can easily use external CSS frameworks like bootstrap nicely and it will only apply to my scope which is nice (example here).
However, this doesn't apply to JavaScript libraries as far as I know. If I, for example, need to work with jQuery on my web component, I basically make it available for entire page. What is the recommend way to work with external JavaScript libraries with Polymer? How should I handle cases where my web component (which is distributed through bower) needs one version of foo.js and the consumer needs another?
There is no JavaScript encapsulation solutions I know of.
Check if js encapsulation solutions exist, e.g. check zonejs and alternatives.
You may do it yourself but this will require you to devote some time to it. E.g. I've encapsulated Babel with with statement as shown here (not tested).
I've written some widgets to use in my web app, and I'd like to be able to plug these widgets in throughout the app without pasting big chunks of widget code. So far I've been writing custom HTML tags and using jQuery selectors and CSS to populate and style my tags. The end result allows me to write <myTag></myTag> anywhere on a page, and have my custom widget appear.
Recently, I've learned about Dust JS and Google's Polymer Project. My understanding is that Dust would allow me to write a template and "swap out" parts of the template with my content, while Polymer would allow me to create custom HTML tags as I've been trying to do and place them wherever I'd like.
Would it benefit me to use Dust or Polymer? What is the difference between those two options and simply using jQuery to select my tags and plug in my widget/styles? Obviously these are three drastically different libraries/frameworks, but it seems to me that there is some overlap when it comes to my use case. Please correct me if I'm wrong.
Edit: Say I have a plain old HTML page. The question I'm getting at is what would prevent me from using {myCustomWidget} in Dust to "plug in" my widget throughout the app, other than the fact that this may not be standard usage? Similarly, why would I use Polymer to create "shortcuts" for my widgets over using a jQuery selector?
Thanks!
I don't know a ton about Dust, but I've made fairly heavy use of both jQuery and Polymer. Someone with more Dust experience should totally weigh in. It looks like one of the main advantages of Dust is that it's designed for efficient server-side rendering. It's also format agnostic whereas jQuery and Polymer are both specialized for HTML.
Polymer is designed for the use case of creating encapsulated widgets that can be easily reused. It's got a few advantages over rolling your own system with jQuery:
A Polymer element can be imported with one line, and the import will pull in its html, js, and css, and it will register the element within the page.
Polymer has support for data binding, meaning that you typically don't have to write code to ensure that the widget is updated after some data changes. When the data changes, all of the widgets that are interacting with that respond immediately and automatically.
Polymer interops really well with jQuery, so if you've got a site that's doing a lot of jQuery style interaction today you can gradually introduce Polymer elements and they'll play well with the rest of your page. e.g.
$('<my-slider>').appendTo('body') // append the slider widget to the page
$('my-slider').attr('value') // get the current value of the slider
$('my-slider').attr('value', 100) // set the value of all sliders
etc
The styling of a polymer element is encapsulated, meaning that a widget will not mess up the rest of the page with its CSS, and the enclosing page won't mess up the styling of the widget (though the enclosing page can style the widget it has to be fairly intentional, just setting something like * { padding: 5px; } won't throw everything off).
There's great docs at http://www.polymer-project.org/ (and after getting started, I strongly recommend the API docs, they're quite complete and informative: http://www.polymer-project.org/docs/polymer/polymer.html )
I've not used Polymer before but I've used Dust and jQuery extensively.
Dust is simply a template library, just like Handlebars,Mustache, Twig and the myriad of other template libraries out there. It's written in javascript and can be used with NodeJS or can easily run in the browser if you're building client side applications.
Both Dust and jQuery can be used together. Dust would render your HTML templates and as always, jQuery would be used to manipulate them and do whatever else you normally do with jQuery such as listen to events and handle them accordingly.
It's important to note that the two aren't alternatives but rather they work together. Dust cannot do the things that jQuery does and is not meant to. Dust works very well when you have large templates that require partials and blocks.
At its core, Polymer is a platform of polyfills for the current implementation of the WC3 web component recommendation as well as some aspects of ECMA 6 such as Object.observe() and WeakMap. Included in the Platform are the libraries NodeBind and TemplateBinding which enable observable (two-way) custom element data-binding.
Dustjs is an asynchronous logic-less templating engine for client-side and server-side(Nodejs)
rendering. There is no native concept of an observable in Dustjs(as is the case for most template engines), meaning two-way data-binding is outside the scope of the project. However, the PayPal roadmap for Dustjs indicates two-way data-binding may receive official support by the end of 2014.
That being said, NodeBind and observe-js are separate repos not necessarily tied to the Polymer custom element implementation, meaning you can use them in your own projects--which is exactly what I did.
My biggest criticism of client-side rendering frameworks like Polymer (and in some respects, angularjs), is that they are not SEO compatible. So I actually combined NodeBind with Dustjs to make my own two-way data-bound custom element implementation derived from the Polymer platform. The idea is that Dustjs renders the template server-side(or even client-side, if SPA) and then upon rendering, you bind the Dust context to an observable and then parse the template fragment for attributes and keys, binding them to a path observer which maps to the observable. So, the bulk of the task is to write your own parser. The good news is that you can use the Dust parser to help your code. The bad news is that if you want to support arbitrary depths, it is far from a simple task(involves quite a bit of recursion). The other non-trivial task is to support path observer rebinding in the event of model list additions and subtractions.
A final note: Dustjs inheritance offers a superior way to reference your custom elements without relying on HTML Imports and ajax like Polymer.
You can do something like this:
{>my-element}
simply as a partial. And in my-element.html
<my-element>
<ui-template id="my-element-frag">...</ui-template>
</my-element>
this does require a second-step in your build process(grunt or gulp) that requires you to not only compile the external files but to parse your external files for your "template tags" and compile those as separate templates, which can then be referenced by, say, the id attribute(as the template name).