So, I'm moving from react-async-component to react-loadable bc of a bug that isn't being fixed. react-async-component has this nifty serverMode that allows you to tell it to never load a component on the server.
This can be useful for admin screens and especially for certain 3rd party components that reference the window object on the server, without checking for its existence.
WhenI used preloadAll, it literally gets everything because there doesn't seem to be a way to exclude items from the selection. Or is there?
It would be nice to see a serverMode option on the Loadable call. But in the meantime, is there a way to exclude certain patterns from being included in preloadAll on the server?
Related
I'm currently implementing a POC project in NextJs 12 to check whether it is possible for us to integrate it. I'm not able to update to 13 yet since I cannot support React 18 due to some in-house packages that we use, so for the purposes of this discussion let's pretend that Next 13 does not exist yet.
We all know that Next officially discourages the use of getInitialProps and recommends using getServerSideProps wherever possible. I'm aware of all the downsides of getInitialProps as opposed to getServerSideProps, main one being the constant client/server context switch which you have to be mindful of.
However, I cannot understand the easiness with which this is discouraged. Apart from NextJs itself I've seen a lot of blog posts calling it the worst thing ever and such. It seems to me like people who say stuff like that have not had some realistic use cases, and that the opinion mostly comes from toy projects (notes app, todo app, blog app etc).
Anyway the purpose of this question is twofold. One, to verify if it is at all possible in my case to avoid getInitialProps, and two, to see if anyone else thinks that this discouragement is somewhat unfounded and not based on reality.
The reason I've decided to use Next at all was to achieve SSR in React. The entire point of that, at least I believe so, is to enable SSR and still preserve some main benefits of React, such as a seamless SPA-like navigation in certain pages. If that was not the case I would have gone for a traditional SSR framework such as Ruby on Rails, Django, etc.
The reason why I need to use getInitialProps, and why I believe I cannot possibly avoid it, is based on two aspects:
Every single page that I have requires certain global data, which I don't want to refetch on every route.
The perfect example of this is the page header. The header of every one of my page depends on user data and translations (i18n). Both of these things I fetch from an external API. If I were to use GSSP then every route and every sub-route of every page would have to re-perform this data fetching which seems like a huge performance kill. I have no way to properly persist this data through GSSP navigation without conforming to some hacks such as sending hidden query parameters which check if data was already fetched. If we were to assume that the user always comes into contact with a page solely through its root URL, then this would work, but this assumption is extremely unrealistic.
By using getInitialProps in combination with redux and next-redux-wrapper, it is very easy to check if data was already fetched (even better if using RTKQ you don't even have to explicitly check it).
Big pages where I want SPA-like behaviour are not possible.
In my case I have one page which has about 5 sub-routes. On its homepage, we display a list of certain entities, which is fetched from the API. The API is such that entities can only be fetched as a list, and you cannot fetch entities individually. Then, for each entity, when you click on it, you can go to a sub-page where you see its specific info.
The only natural way to do this is to have the entire data fetched on the first page visit and then reused throughout the page as we navigate. Re-fetching the whole data on every page navigation is also a performance kill. The only way I was able to implement this and preserve a seamless SPA-like navigation was with getInitialProps.
What's interesting about this use case is that hacks with sending hidden query params would actually not do the trick, since even though I can force GSSP to be aware that the data is already fetched, I cannot access that data, therefore I cannot do any server-side route validation. What I mean is that if a user was to land on the home page, where all the entities are fetched, then somehow visit an entity page, like page/123, where an entity with id 123 does not exist, I cannot validate that and properly handle it in GSSP without re-fetching the entire list of entities again which is, once more, a performance kill.
So, in conclusion, I'd like to hear opinions on the discouragement of getInitialProps. For me it seems borderline impossible to completely migrate to getSeverSideProps if your app is at all realistic, uses translations, global data, etc.
Thanks in advance.
Is there a way or tool that could let me step through the painting of CSS rules, one by one?
Similar as one would do in an IDE with program code, but with CSS. (But I wouldn't preferably want to do it by taking the browser's source code and stepping through its underlying functions - I just mean stepping throug "updates" by CSS rules, in a form similar to a Web Developer Toolbar.)
I expect this is usually more tedious than useful, but in some cases it would really help, in web development, like debugging cats and owls or finding out how a particular effect is achieved.
edit to clarify, by "stepping through" I mean sg. like: potentially stopping the browser from painting another rule, after each end every rule I choose, before the next one is applied (each before the "final paint" of the page is finished), for inspection of what happens.
edit 2 after BoltClock's comment, I replaced the word 'render' with 'paint', to be more clear. Removed original to be uncluttered.
Beside already mentioned webtools i guess this is only possible if the complete source code of the browser is available so its possible to either locally debug or remote debug the browser application itself with breakpoints set to the interesting "toplevel" functions.
It is for example no problem to download the source of the Java based open source browser Lobo which can then be debugged like any other application directly from your IDE like eclipse, intellij etc.
I however dont think the complete source of products like the MS Internet Explorer will ever be fully available to allow you to debug its deepest magic (which in case of MS Internet Explorer probably also takes a livetime...).
So coming back to a browser that has source code available you can either:
Have the browser beeing compiled/ run inside a IDE and directly debug your local code
Have the browser running as application allowing remote debugging and the according source code as source for a remote debugger (mostly as well from within your IDE).
This way you can analyse the deep magic of such a browser where you see how the different resources like images, css etc. etc. are collected, validated, parsed, processed and in the end displayed.
Once the interesting functions are located and a good set of (conditional) breaktpoints is set this could be very useful when it comes to the behaviour of a specific browser.
If that however is too detailed for your context i guess there is no other possibility but to rely on the already given functionality regarding analysing the browsers behaviour like with chromes devTools or the Mozilla plugin Firebug. No doubt this will more and more be integrated in such plugins/ tools like the comment of user BoltClock suggests and it is always worthy to study the functionality of such plugins/ tools to take the biggest possible advance of them.
We all know that we're supposed to combine our CSS into one file, but per site or per page? I've found pro's and cons to both.
Here's the scenario:
Large site
CSS files broken out into one file for global styles and many for modules
Solution A: Combine ALL the CSS files for the whole site into one file:
Best part is that the one file would be cached on every page after the initial hit! The downside is that naming convention for your selectors (classes and id's) becomes more important as the chance for a namespace collision increases. You also need a system for styling the same module differently on separate pages. This leads to extra selectors in your CSS which is more work for the browser. This can cause problems on mobile devices like the iPad that don't have as much memory and processing power. If you're using media queries for responsive design, you're troubles compound even further as you add in the extra styles.
Solution B: Combine one CSS file per page template:
(By page template I mean one layout, but many different pages, like an article page)
In this scenario, you lose most of the issues with selecting described above, but you also lose some of the cache advantages. The worst part of this technique is that if you have the same styles on 2 different page templates then they'll be download twice, once for each page! For instance, this would happen with all your global files. :(
Summary:
So, as is common in programming, neither solution is perfect, but if anyone has run into this and found an answer I'd love to hear it! Especially, if you know of any techniques that help with the selector issue of Solution A.
Of course, combine and minify all the global styles, like your site template, typography, forms, etc. I would also consider combining the most important and most frequently used module styles into the global stylesheet, certainly the ones that you plan to use on the home page or entry point.
Solution B isn't a good one: the user ends up downloading the same content for each unique layout/page when you could have just loaded parts of it from the last page's cache. There is no advantage whatsoever to this method.
For the rest, I would leave them separate (and minified) and just load them individually as needed. You can use any of the preloading techniques described on the Yahoo! Developer network's "Best Practices for Speeding Up Your Web Site" guide to load the user's cache beforehand:
Preload Components
By preloading components you can take advantage
of the time the browser is idle and request components (like images,
styles and scripts) you'll need in the future. This way when the user
visits the next page, you could have most of the components already in
the cache and your page will load much faster for the user. There are actually several types of preloading:
Unconditional preload - as soon as onload fires, you go ahead and fetch some extra components. Check google.com for an example of how a
sprite image is requested onload. This sprite image is not needed on
the google.com homepage, but it is needed on the consecutive search
result page.
Conditional preload - based on a user action you make an educated guess where the user is headed next and preload accordingly. On
search.yahoo.com you can see how some extra components are requested
after you start typing in the input box.
As far as the conflicting selectors go: combining all the files and doing it any other way should not make a difference, this is a problem with your design. If possible, have all modules "namespaced" somehow, perhaps by using a common prefix for classes specific to the module, like blog-header or storefront-title. There is a concept called "Object-oriented CSS" that might reduce the need for lots of redundant CSS and module-specific class names, but this is normally done during the design phase, not something you can "tack on" to an existing project.
Less HTTP requests is better, but you have to take file size into consideration as well as user behavior and activity. The initial download time of the entry page is the most important thing, so you don't want to bog it down with stuff you won't use until later. If you really want to crunch the numbers, try a few different things and profile your site with Firebug or Chrome's developer tools.
i think you can make global.css that store style that need every template.
And you could make css in each template.
Or simply use css framework like lescss
We are loading external swf content into an adobe air application. Content is provided by an increasing number of third parties.
Being third party content, it will be loaded in a separate security domain (trustContent=false) and a sibling app domain (loadForCompatibility=true). We are doing this using the Loader class.
What are the features/options/approaches that would cause problems when using the swf as external content?
I am interested in any kind of issues, as we have already reproduced issues with content that occur regardless of the app domain / security domain where its loaded ( and occurs also in both Loader and SWFLoader).
Any workarounds for the issues are highly appreciated, especially ones that can be applied from the main app.
The big nasty problem (and one we've dealt with a lot!) is the fact that external SWFs simply can not be directly trusted. Ever. This makes communicating between them and the base AIR application difficult at best.
There is a hack around this based on loading the data of the SWF via a URLLoader and then taking the bytearray from it and pumping it into a Loader. However, I believe that hack was killed with AIR 1.5.1.
That being said, it is possible to communicate between the AIR app and the loaded SWF through what Adobe calls the sandbox bridge. However, setting up the sandbox bridge is a royal pain and any complex data (objects, even as simple as Arrays) get stripped down to generic objects on the other side of the bridge and can not be cast back to their original form.
For our recent projects that needed to use the bridge we created a specialty class called AIRBridge that you use on both sides of the bridge and it facilitates setting everything up properly. If you're interested, you can pull the current source from our Google Code project Automata-Tools.
One we already addressed:
Content outside of the external swf stage shows in the application, and when setting the size where it will be displayed the offstage elements are taken into account. Workaround: Add a mask on the main app so the external content is hidden. Use .content.width/height (full with offstage elements) and .content.loaderInfo.width/height (original stage size) to calculate how much to scale content so the original stage matches the visible area.
I have one swf file in that i used fscommand to get final output when submit button clicked in that swf ,
i am loading that swf in SWFloader in flex3 .i need to get fscommand value as Alert, how to get that value first and display as alert.
Thanks in advance
fscommand cannot be used for communication between loaded and containing SWFs.
From livedocs
fscommand: Lets the SWF file communicate with either Flash Player or the program hosting Flash Player, such as a web browser. You can also use the fscommand() function to pass messages to Director or to Visual Basic, Visual C++, and other programs that can host ActiveX controls.
You can call a method in the loaded swf OR access its properties directly OR use events OR use local connection to pass data between parent and loaded SWFs.
TECHNICALLY this is feasible, but a bad idea. You'd need to register a callback which would call the child swf (generally done from the child swf). But, you will risk a good deal of headache, and you'll have to rely a lot more on the browser than other options. It would also be slower than an AS only solution.
You're much better off (in this order):
Using a shared Singleton. This allows for complete separation of the two
swf's without requiring any major coordination between the two. The only
real potential problem can be caused if you want the child swf to have its
own ApplicationDomain, but even with that, there are work-arounds
Using events. This can work if you have the child swf dispatch a bubbling,
non-cancel-able event and have the event.target recorded by the
parent swf. You may have to adjust to avoid
SecuritySandboxViolations, however.
Using LocalConnections. The two detriments to LocalConnections are:
You will need to continually re-generate unique connection names to
avoid the error thrown by connecting two LocalConnections to the same
channel.
LocalConnections do have bandwidth limitations which can call
slowdowns if there is a high volume of traffic or if the messages are
too large.
Using direct manipulations like loader.content.foo.bar.baz;
I don't like this solution because it is much harder to maintain. It is
also much worse from a design perspective: you want to use
encapsulation as much as possible in this situation -- this technique
actively works against that.