Is it really that slow? Should it be so, or something's wrong with my implementation?
P.S. 2 input fields form with one button.
Without styled-components: (523ms Scripting)
With styled-components: (3161ms Scripting)
Yes, Styled Components is slow because it's a CSS-in-JS solution. This means your page must go through these steps:
page is loaded;
JavaScript code is parsed;
CSS is generated;
CSS is injected into components;
browser renders the CSS.
When you have plain CSS files (like when you use CSS modules), the steps are:
page is loaded;
JavaScript code is parsed; browser renders CSS in parallel.
Styled Components gives you the powerful ability to inject code dinamically into the CSS, but there is no free lunch: and the cost here is performance. In the long run, the best solution to me seems to be SCSS modules (that is, CSS modules combined with SCSS).
Then, if you need to inject code into the CSS, simply set CSS --variables dinamically.
Related
I am new to Liferay, and I still don't know the difference between the various 'kind' of Liferays.
This Liferay is what I am talking about.
I understand that you have to create a page first, and then add components (fragments) in it.
I also understand that you can go to fragments, and create a custom fragment with a custom CSS, and then import it into your page.
However, what I want to do is have a global CSS that I can use for all fragments inside a page, rather than having to add CSS for each fragment.
Is that possible, and if so, how?
I know I can use the 'style-books' which apply to an entire page, however, I don't know how to customize them, and it doesn't seem that that's even possible.
To avoid coding, you can use the css additional textbox provide by theme settings.
It's a whole page css addon for every pages in the site
Using 2sxc on DNN, I have a website that uses SVGs for icons in content types. The client wants to be able to upload the SVG icons to 2sxc via a Link field but then instead of rendering <img src="#Content.SVG" />, they want it to render the source code of the SVG (so we could manipulate the fill color via CSS). Is this even possible and how could it be done?
Basically 2 steps
Get the real file name using 2sxc and DNN
Then load the file as a string using normal .net stuff System.IO and add it to your html - https://learn.microsoft.com/en-us/dotnet/api/system.io.file.readalltext?view=netframework-4.5.1
ca. like this
<div>
#Html.Raw(System.IO.File.ReadAllText(fileName)
</div>
Some examples of how to do this can be found below
Using the fetch API
How to convert image (svg) to rendered svg in javascript?
Older methods such as XMLHttpRequest or jQuery
Include SVG files with HTML, and still be able to apply styles to them?
Using D3
(Embed and) Refer to an external SVG via D3 and/or javascript
Using a custom JS library
One example: SVGInjector
Interestingly Dnn is doing this nowadays and you can look at the code here. If you ignore the caching, you might be able to do similar in a View.
https://github.com/dnnsoftware/Dnn.Platform/blob/0d3b931d8483b01aaad0291a5fde2cbc0bac60ca/DNN%20Platform/Website/admin/Skins/Logo.ascx.cs#L123
And that is called from above, see ~line 71, so they are doing a real inject of the file contents to inline. Obviously caching file-access stuff should be a priority for caching if the website is high-traffic, but otherwise it is not needed or at least secondary.
I am trying to use a 3rd party javascript control, Owl Carousel. The way I am reading the documentations is this:
In the zip file from Owl Carousel there is a folder called owlcarousel that contains the javascript and another folder that contains all the supporting files which need to be copied to /modules/base-accelerator/yacceleratorstorefront/web/webroot/_ui/responsive/common. Then I simply need to go into the javaScript.tag file and add this line towards the end of the file:
<script src="${commonResourcePathHtml}/owlcarousel/owl.carousel.min.js"></script>
Upon trying that, I get all sorts of loading errors and no images are display, even without using the control. So my question is:
What is the correct approach to include a 3rd party javascript?
Is there any way to control which pages actually get a javascript file or do simply ALL the pages get ALL the javascript includes?
See if "Storefront Web Application Deconstructed" will help: https://help.sap.com/viewer/4c33bf189ab9409e84e589295c36d96e/1905/en-US/8af03fda8669101491e4aac2acaeb2dd.html
web/webroot
_ui: Contains the JavaScript and CSS styling for the current theme.
shared/js: Shared JavaScript used by desktop and responsive pages.
responsive/common: Commonly used style sheets, JavaScript libraries and images.
responsive/theme-alpha: The blue theme definition.
responsive/theme-lambda: The black theme definition.
WEB-INF
_ui-src: Contains JS testing, full libraries, and the Less files used to generate the CSS for a theme.
common/tld: The tag library descriptor files for the CMS and ycommerce tags.
config: Spring application context files.
lib: The libraries required by the storefront.
messages: The localization files.
tags: The tags that are used within views.
views: The JSP pages, fragments and CMS components.
I understand that the background page of a Chrome extension is never displayed. It makes sense to me that a background page should contain only scripts. In what situations would HTML markup ever be needed?
At https://developer.chrome.com/extensions/background_pages there is an example with an HTML background page, but I haven't been able to get it to work (perhaps because I am not sure what it should be doing).
Are there any examples of simple Chrome extensions which demonstrate how HTML markup can be useful in a background page?
Historical reasons
The background page is, technically, a whole separate document - except it's not rendered in an actual tab.
For simplicity's sake, perhaps, extensions started with requiring a full HTML page for the background page through the background_page manifest property. That was the only form.
But, as evidenced by your question, most of the time it's not clear what the page can actually be used for except for holding scripts. That made the entire thing being just a piece of boilerplate.
That's why when Chrome introduced "manifest_version": 2 in 2012 as a big facelift to extensions, they added an alternative format, background.scripts array. This will offload the boilerplate to Chrome, which will then create a background page document for you, succinctly called _generated_background_page.html.
Today, this is a preferred method, though background.page is still available.
Practical reasons
With all the above said, you still sometimes want to have actual elements in your background page's document.
<script> for dynamically adding scripts to the background page (as long as they conform to extension CSP).
Among other things, since you can't include external scripts through background.scripts array, you need to create a <script> element for those you whitelist for the purpose.
<canvas> for preparing image data for use elsewhere, for example in Browser Action icons.
<audio> for producing sounds.
<textarea> for (old-school) working with clipboard (don't actually do this).
<iframe> for embedding an external page into the background page, which can sometimes help extracting dynamic data.
..possibly more.
It's debatable which boilerplate is "better": creating the elements in advance as a document, or using document.createElement and its friends as needed.
In any case, a background page is always a page, whether provided by you or autogenerated by Chrome. You can use all the DOM functions you want.
My two cents:
Take Google Mail Checker as an example, it declares a canvas in background.html
<canvas id="canvas" width="19" height="19">
Then it could manipulate the canvas in background.js and call chrome.browserAction.setIcon({imageData: canvasContext.getImageData(...)}) to change the browser action icon.
I know we could dynamically create canvas via background.js, however when doing something involving DOM element, using html directly seems easier.
I am trying to customize the Liferay UI by using custom theme using base as as "_Styled" theme.
I have my own css files which I coped to _diff/css folder of theme and imported them "custom.css" file .However its breaking the presentation of liferay.In my custom CSS I have styles defined for all the standard tags like body,div etc which is impacting the liferay UI too.
How can I resolve this conflict? Thanks in advance!
Quick (and not the best) solution is to remove contents of liferays css file (for example "base.css") and save this empty file in /diff/css/ folder of your theme. This way the base.css will get overriden with your new empty file and thus no styles will get loaded. And your custom.css will be the only stylesheet that is taken into account.
Well, of course it all has an effect on the rest of Liferay as well. Liferay provides quite a bit of the HTML DOM of your page, and if you change the presentation of all of those elements, you'll have to take care to style Liferay's elements too.
Is this a conflict? No. Let's go for the simplest case: You declare div {color:green;}. Of course, now everything, your components as well as Liferay's components, use green text. If you only want to style your own portlets, you might want to specify some portlets: div.portlet-my-own-application {color:green;}
I know that color is a too simple usecase, but I hope it illustrates the solution strategy.
Rather than following Artem Khojoyan's suggestion to override Liferay's base.css, I'd recommend to take a look at the resulting css, what's effective etc., and simplify your own css - adapt it to be used within Liferay - by inspecting the effective CSS for every elements that looks off. Firebug or any of it's relatives are your friend.
I'm afraid, with the details "I'm doing something which has an effect on Liferay UI" there's nothing much more to help you. In fact, I'd hope that what you do has an effect on Liferay's UI... You'll just need to find the proper CSS code
Ideally if your styles are loaded from custom.css, then will overwrite liferay default styles.
In some cases, to overwrite a style in css, you can use !important
for example, liferay default style
body {
background-color: #fff
}
You can specify your style to consider irrespective of order of loading
body {
background-color: red !important;
}