(or similarly named depending on library)
Are these functions purely for ease of use in accessing the theme within an app or do they provide some functional/performance benefit?
What is the difference between me accessing a theme directly by importing it into a component or accessing it through the ThemeProvider?
I think any performance deficit or gain is negligible. They do however provide ease of use, as it is easier to get the theme inline, like color: ${(theme) => theme.colors.primary} without having to import the theme file each and every time. There are also helpers for this to make the access less verbose.
Another big benefit is when you need to use different themes or swap them on the fly. A ThemeProvider will update as needed, and you can even use different theme variations nested within the main theme. Really helpful if you're doing dark mode etc.
Related
In React, some packages allow you to import Components using either individual assignment: import Card from "#material-ui/core/Card", or via object destructuring: import { Card } from "#material-ui/core".
I read in a Blog that using the object destructuring syntax can have performance ramifications if your environment doesn't have proper tree-shaking functionality. The result being that every component of #material-ui/core is imported, not just the one you wanted.
In what situations could using object destructuring imports cause a decline in application performance and how serious would the impact be? Also, in an environment that does have all the bells and whistles, like the default create-react-app configuration, will using one over the other make any difference at all?
Relying on package internal structure is often discouraged but it's officially valid in Material UI:
import Card from '#material-ui/core/Card';
In order to not depend on this and keep imports shorter, top-level exports can be used
import { Card } from "#material-ui/core"
Both are interchangeable, as long as the setup supports tree-shaking. In case unused top-level exports can be tree-shaken, the second option is preferable. Otherwise the the first option is preferable, it guarantees unused package imports to not be included into the bundle.
create-react-app uses Webpack configuration that supports tree-shaking and can benefit from the second option.
Loading in extra code, such as numerous components from material-ui you may not need, has two primary performance impacts: Download time, and execution time.
Download time is simple: Your JS file(s) are larger, therefore take longer to download, especially over slower connections such as mobile. Properly slimming down your JS using mechanisms like tree shaking is always a good idea.
Execution time is a little less apparent, but also has a similar effect, this time to browsers with less computing power available - again, primarily mobile. Even if the components are never used, the browser must still parse and execute the source and pull it into memory. On your desktop with a powerful processor and plenty of memory you'll probably never notice the difference, but on a slower/older computer or mobile device you may notice a small lag even after the file(s) finish downloading as they are processed.
Assuming your build tooling has properly working tree shaking, my opinion is generally they are roughly equivalent. The build tool will not include the unused components into the compiled JS, so it shouldn't impact either download or execution time.
I am very eager to learn in the area of web-development and lately I started learning server-side programming after doing front-end web-development first.
Now it appeared to me that there are some templating languages such as jade/pug. However I cannot seem to fully understand the concept/purpose of these languages.
Do you first create your front-end part using html5 and css and then
convert this html to pug in order to use it for server-side
programming?
if so, why not just use html?
Or do you actually create your webpages using pug from scratch?
I do understand that a lot of information can be found with a quick google search. Therefore I want to emphasize that I actually did a lot of searching already. However, I cannot seem to fully grasp the concept or maybe I don't ask the right questions.
Therefore, I would really appreciate it if someone could explain what the exact role of these templating languages is in web development so that I understand the bigger picture.
I am using pug for three main reasons:
less to write (CSS selector like syntax, no closing tags)
better readability because you are basically writing the DOM instead of tags
the "extends" functionality to avoid duplicate code
Other (obvious) reasons are the possibility to use variables, loops, if-statements or even function calls to format or transform data in any possible way.
I usually create a layout.pug file containing everything that is contained in every page plus a block main and other views that extends layout. Depending on the project I also use a block head and block script to allow specific pages to inject additional stylesheets or scripts.
I got used to only writing pug code combined with stylus which concept is quite similar, so having to write plain HTML or CSS from time to time even got annoying.
Pug is also great in combination with bootstrap and/or Angular so I see no reason not to use it.
I am looking for a solution outside of Organic Groups (I think it's too heavy for this purpose).
I suspect this will require a programmatic solution so I am open to any suggestions
Without using Organic Groups, I think you would have to either write a custom module that does exactly what you want, or you could try to "piece it all together" with other contributed modules such as Rules, CCK, etc.
You could try to use nodereference to link the employees/managers together from their profile (if using content profile), but then to handle permissions for those managers I think you would need a custom module anyway. I have a feeling that you will have to write your own module as piecing something together like that would be a real mess, not flexible, and more trouble than it's worth in the end.
I read many times that YUI will load modules dynamically based on need. or based on parent module. Like here it is written
The overlay module will pull in the widget, widget-stack,
widget-position, widget-position-align, widget-position-constrain and
widget-stdmod extensions it uses.
So, how can I determine the final size of data getting downloaded for a web page due to YUI usage.
Actually I was thinking how one can compare the datasize of YUI with that of another library (JQuery).
If you want file size vs functionality comparison, a close approximation based on features would be the simpleyui.js package (though the feature compilation is not 1:1), and be sure to look at gzip size as Tivac said.
Also keep in mind that JS lib file size comparison used as a reason to choose one over another is often a red herring. Your site likely includes a number of images, many of which will easy be larger than the lib and several additional modules. More relevant comparisons would be how the library is structured, what its relative strengths are, what's included out of the box (officially supported features vs 3rd party plugins), its community and documentation, etc. Pretty much any lib will serve your basic DHTML needs, and neither you or your users will notice the difference. Choose what works for you, and helps you build clean, maintainable code that you or your successor won't hate in a few months.
The Configurator will give you a file-size breakdown & automatically selects the needed modules.
I'm a Linux user, and I have been very hesitant to use Glade to design GUIs, since the xml files it produces can easily be modified. I know it doesn't sound like a major issue, but what if it's a commercial app that you just don't want people changing?
I use Mac OS X every once in a while, and I figured out that they use files called ".nib"s for GUIs. I think they're essentially the same type used in Nextstep and Openstep (there's even a Linux app which lets you edit these files). Anyway, these files are included in the application bundle, and according to some people, are completely editable. This person claims he even successfully edited Keynote's interface.
Now, why would that be possible? Is it completely okay for the end user to change the interface? Or is it better to have the GUI directly in the compiled application code, like traditional GTK apps?
OS X nib files are one option; the other option is to do things programmatically. For android, XML files can define the GUI or program code can do it. In Windows WPF, the UI is made in XML. Firefox/Mozilla? XUL, another XML-based UI language.
Most modern GUI toolkits have either both of these options or even just defining UIs in files.
But even binaries are modifiable. With a good binary reverse engineering tool, it's wide open. The only way to be really certain is to do what Apple did with iOS, and run signed code; the entire bundle is signed by a key and can't be run if modified.
This isn't a problem for most everyone. Why do you care if the UI is modified? The underlying code isn't, so functionality can't be added or modified.
As a corollary (and a little off-topic) something that you might have a valid concern about is stuff a little more like this.
I don't really see a problem with it. If a user messes up his UI, then it's his problem. Think of it like moddable games. Users always loved them, and in the end, most games benefit from it. There is usually nothing secret about an application's user interface. If there is, you could always do some sort of encryption.
As others have said, you can also add checksums if you just want to disallow editing.
The xml specifies little more than what the interface looks like. Without the compiled-in event handling code, it's pretty much useless. My opinion is customers change it at their own risk, and you might actually get some free useful improvements out of their hacks.
If you're really paranoid about people changing it, you could always add an MD5 digest verification step or something when you load the xml, or compile the xml string into a header file, but that defeats many of the benefits.
The theming engine can make substantial-looking changes to your GUI, as can tools like Parasite. Updating the Glade layout — at their own risk — is much safer than either of those.
What's wrong with users customizing the UI anyway?