we have a pretty large Angular v13 app which uses ngrx.
Some parts of our application are quite slow. As part of my analysis, I would like to know which - selectors are being fired.
Is there a way to generically add a console.log to the selectors? Something like:
console.log('selector foobar fired!). I want to avoid to add console.log statements to every single one, though.
This is how we create our selectors:
export const selectUser = createSelector(selectAuthState, (state: AuthState) => state.user);
No, this can't be done with the current API.
However, you can go to your node_modules find the selectors file and add a console log there.
Then, to be sure, you'll also have to clear the angular cache and re-serve the application.
You could also use the DevTools, or the Angular DevTools to find the culprit.
Related
Wondering if anyone can lay out how one avoids a situation wherein a React application that uses material-ui classNames from makeStyles, and which includes a package that ALSO does that, hence two name generators, results in multiple, conflicting .jss1, .jss2, etc. in the production rendered page that includes both the app's components as well as the included package's.
I have control of both, so I can modify either to have a prefix, but I'm not at all clear on where one injects that into a v4 material-ui project.
Now, I know that createGenerateClassName allows one to pass in a prefix, but it's not clear to me how one injects that into the ThemeProvider. I wrapped the whole thing in a StylesProvider and passed the resulting generateClassName to that, but that seemed to be ignored.
Well, allow me to answer my own question for future generations. Turns out that you can indeed wrap the ThemeProvider with a StylesProvider with a generateClassName argument:
const generateClassName = createGenerateClassName({
productionPrefix: 'coreJss'
});
...
<StylesProvider generateClassName={generateClassName}>
<ThemeProvider theme={MyTheme}>
Stuff
</ThemeProvider>
</StylesProvider>
Now, your production classNames will be coreJss1, coreJss2... for that package and jss1, jss2...
Now, you might ask 'why didn't yours work in the first place?' and I would tell you to pay close attention to what you actually committed vs. what you typed and didn't save.
So I decided on taking it upon myself to make a React template with Deno as the backend. So far its been a good balance between learning something that is familiar (React) and new (Deno). Ultimately I would like to make it usable so that anyone using React can download it and get right in. With that said, there is one issue I am having and its with CSS.
While I can import the components CSS into my component, Deno does not recognize it when running the server. It will throw an "Unknown MediaType" error. So far there is only 2 workarounds I've found:
Use inline styling and turn the CSS for that attribute into an object.
Put all the CSS into the static file thereby making the file longer.
Personally I would choose the second option than the first because at least I could use stuff like media queries. I have tried using the ESM version of the "styled-components" module yet that doesn't work either. Can anyone share what they have been doing?
Solved it.
I ended up using the ESM version of the "styled-components" module and then set up the server-side rendering in the response body. Cant believe this gave me 2 weeks of headaches.
I've been surfing StackOverflow and the Nuxt documentation, but I cannot get my head around this one.
So, I need to do RTL. My project is in Nuxt and we use SCSS. I'm setting the htmlAttrs to dir="rtl" conditionally depending on a store getter that tells me if the language is RTL or not. The requirement for this specific task is that a RTL stylesheet should be imported conditionally from the server side also if the country is RTL, so that it overrides the main.scss file.
Now, in nuxtServerInit(), I cannot set the stylesheet in the head, because the route will not direct me to the file, and, most importantly, Webpack won't compile it, as it's outside the regular flow of the application and not imported by main.scss, which is the stylesheet the Nuxt config is pointing to, and which contains all other styles. I realize that I could use a class and use it conditionally in components, but that is not the requirement. The nuxt.config.js file, in the relevant part, looks like this:
css: [
'#/assets/styles/main.scss'
]
There I obviously don't have access to the store.
What I said I tried was this:
if (isRTL) {
service.addEntryToArray('link', {
rel: 'stylesheet',
type: 'text/css',
href: '../assets/styles/main.rtl.scss'
});
}
(We use a service to add things to the head)
I understand that was naive on my part, because Webpack has no say there, so there is no transpilation, and there is no actual asset, which means the route is just wrong, and even if it were right, the browser would not be able to read it.
Any ideas on how this could be achieved at a non-component level? This needs to be part of the Webpack flow, has to be added server-side, and needs to be an import --I cannot just import it regularly and use just a class (again, I'm not stubborn, I'm working on a project, and this is a requirement by the client).
If you need more information, I'll update the post, but I don't know what else to provide.
I'm using CSS Modules (Sass) with rollup on a component library project, which is working well. Each component ends up with a dist folder containing a single JS bundle file, and a corresponding CSS file with the scoped CSS classes so consumers of the component don't have to worry about CSS class name conflicts. All they do is include the JS bundle and the CSS file and everything is great. Yay CSS Modules.
The problem I'm now facing is that some components really need separate "themes" - ideally, separate CSS files, one per theme. So consumers can continue as they've been doing: including the JS bundle, but now choosing which CSS file to include to pick a theme.
I'm not sure how to get this going with CSS modules & rollup, and whether this is even the sort of approach others are taking. From what I can see, rollup always handles bundling things together, whereas I want separate CSS files, all of which get their classes renamed identically during the build phase. That way, if within my JS I refer to styles.myclass, if myclass had gotten renamed to scoped-myclass by CSS modules for the original CSS file, for a second CSS file it would also get the same name.
This would keep consumption of the component extremely simple - just a matter of including a different CSS file.
Any suggestions?
Awfully late, but let me answer this 3 years on. So what I ended up doing was totally detaching the CSS generation step from rollup and relying on the Sass CLI to handle that portion of the build process. It felt a bit klutzy, but I remember it wasn't awfully hard to do and solved the problem I outlined above. I don't believe there was a plain rollup solution at the time, nor do I think there's one today.
However... in my case the whole approach was kinda mistaken. This certainly won't be everyone's scenario, but let me spell it all out because hey it may be useful and it definitely wasn't obvious to me at the time.
This was for an in-house shared component library, where each component and its corresponding CSS was a separate npm package stored in our Artifactory. When it grew, plenty of internal references popped up, e.g. multiple components would reference the Button component, and over time they'd reference different versions of the Buttons component - each of which needed its own properly scoped CSS, unique to that package-version.
So what I found was that by doing it this way - having the CSS generated as part of the npm package dist files - I had to write an additional layer for the consumer applications that would parse their node_modules/ folder for our own internal components and combine all the different CSS files, such as the multiple versions of buttons. e.g. the main application would directly import buttons v1.0.0 in its package.json file, but the Dialog component (also included in the package.json) could include buttons 2.0.0 as its own dependency. For every version of the package, there was a uniquely scoped version of the CSS - so the consuming application HAD to include every version otherwise the styling would be borked.
So all in all, it ended up being way more complex that I wanted. I thought I could make it easier & better with the separate generated themed CSS files as part of the package dist, but it didn't end up that way. If I could revisit that project today, I'd re-examine a solution used by Material UI and others which I kinda poo-poo'd at the time: automatic injection of the CSS into the page by the component JS, rather than generating standalone CSS files which required extra work by the consumer applications to gather up and add to the final webpage. Frankly, now I regard it as the "least crap". There are definite downsides to the injection approach (extra work done on every page render for everyone! Yikes!), but there's no doubt in my mind it hugely simplifies the job of the consumer applications. It's a balancing act, but in 20-20 hindsight I'd lean towards the injection approach. With that, scoping & theming is a different and much simpler problem.
If I got you right, consider looking at SCSS plugin: rollup-plugin-scss. It captures all spare .css files imported in the components, and then processes them through underlying node-sass. The catch is, it seems like you can write a custom callback function that'd handle your CSSs differently based on conditions you throw in.
Based on the example from the plugin's page:
import scss from 'rollup-plugin-scss'
...
export default {
input: 'src/index.tsx',
output: [...],
plugins: [
...
output: function (styles, styleNodes) {
// replace this with conditioned outputs as needed:
writeFileSync('bundle1.css', styles)
writeFileSync('bundle2.css', styles)
},
]
}
I have the Less package loaded in my Meteor application and it is working fine. Now I need to allow the users of my app. to override my less variables. I have looked at :
less.modifyVars({
'#canvas': '#5B83AD'
});
but my app. is saying that 'less is not defined'. Can someone suggest how this can be done?
Less files can only be modified up to the point they're compiled to css files. This happens when you deploy your Meteor app.
It's not possible to change less variables at runtime. You would have to manipulate the DOM instead. Jquery is able to do this by targeting the DOM elements you want to change. You would have to tag them with a class.
An approach this way make work for you:
<div class="canvas"></div>
Then you could edit it at runtime using Jquery:
$(".canvas").css({background: '#5B83AD'});
Edit: I think the code you're refering to is the less.js client side file from https://github.com/less/less.js/. There's a bit more info under 'Client side usage' on http://lesscss.org/
This is a bit different from the Meteor less package, which is exclusively a server side compiler during development.
If you downloaded the less.js file (from https://github.com/less/less.js/archive/master.zip) and placed it in your /client/compatiblity folder you could use it in the way you wish. Keep in mind you may have to remove the Meteor less package since you want to load them raw, you will also need to reference them manually as Meteor will ignore the less once you remove the less package.