I've just imported a Flex component into my project.
I have a theory question about importing.
all the imports statements in the component source files started with "com.subFolder.etc", but I have preferred to move the component folders into "componentName" and to replace all import statements as "componentName.com.subFolder.etc"
Is this ok ? Everything works perfectly, but I was wondering if the method is correct.
thanks
You can put the components anywhere you like, however you want to organize them. People will site best practices and theory but if you know where everything is and you tell the compiler where they are:
import componentName.com.subFolder.componentToBeUsed;
Everything will compile and run just fine.
Usually you will see code and components broken up in a domain model.
So you'll have:
com.yoursite.views
com.yoursite.events
com.someothersite.renderers
Which correspond to:
/com/yoursite/views
/com/yoursite/events
Basically all of your code living in folders within /com/yoursite/
and:
/com/someothersite/renderers
being a custom renderer you imported from someothersite.com to use in your application.
In the end, for the compiler and the flash player I don't think it matters where you put things as long as your happy and understand it all...and of course 6 months from now when you come back to look at this code!
It's totally correct, yes.
Note that Flex Builder (if you're using it) can automatically replace your import statements/class name when you rename a directory or a .mxml/.as file.
I never tried moving a complete structure, though, but I would't be surprised if it worked too.
Related
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.
When I create Angular application, I am using CLI for generating components. After certain time of developing app I have style file for every component but major part of them are empty.
When I check sonar I have Code smells in empty style files:
Remove this empty stylesheet.
Add an empty new line at the end of this file.
Should I remove sonar rules or I must delete all empty style files in project and recreating them in next versions of project when I need them for component styling? What are best practices?
For me, you can let the CSS / SCSS files empty.
Just because after the build everything around styling will be minified and contained the "styles.js" file.
So, even if it's a bit ugly to see all these empty files in dev mode, the compiler will solve your probelm by itself
this is a screen of your project after build :
The main question is: empty scss files... What are best practices?
Empty files in a project is a bad practice.
no one like to have useless files in their file browser.
I am against #AbhishekAnand answer "the compiler will solve your probelm by itself":
The compiler did not solve the problem for me, the empty files are uglier and I still can't tell the benefits of minifying an empty files.
My opinion is to remove the "styleUrls" from the component, delete the empty scss and create it when you need it.
It will feel good like you just loose weight!
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 can't seem to import this bootstrap theme to my rails application.
https://github.com/puikinsh/sufee-admin-dashboard
I am trying to import this template for two days but no luck. It could be easy, but I don´t know what I´m doing wrong :(
I receive this error:
Undefined variable: "$border-color".
Undefined mixin ....
So I have got a problem with variables and mixins at the first time. I tried another template and it works, so I really don´t know what to try next.
Any hint or idea about how to solve this problem would be really appreciated.
Thanks
Porting a template into your Rails application is not hard if you break it down into several imprortant steps:
Import styles. From what I can see, your template is using sass along with plain css style files. You can pick one of those and copy the files into your /app/assets/stylesheets folder and importing them in your application.sass. The Undefined variable: "$border-color". points you towards missing variables.scss, which contains all the color variables for your template.
See if your template is using any third-party libraries or frameworks. In this particular example, there is a list of them in the repo's "Built With" section of the readme. Go through every single one of them and find gem versions of those libraries and add them to your Gemfile.
Copy non third-party Javascript files into your app/assets/javascripts. Require them in pagedown.coffee.erb along with third-party modules. Be sure to keep non third-party code below other modules to preserve functionality of code that relies on those modules.
Trim HTML templates into views. Figure out what part of your layout should be preserved for every page and put it into your layout view, break down the rest into controller-specific views.
There can be a lot of problems, but in general, just try to analyze the errors being thrown and solve them one by one.
I recently setup django-grappelli on my first django app. While I like the way it looks I want to customize the colors, and other CSS.
From my research, it looks like I will have to use Compass but I've never used Compass before and want to double check that this is the best method before I embark on that path!
Is Django-grapelli even the right choice for some one that wants to customize the color theme?
Things I tried
Modify the CSS in the Grappelli stylesheets but they are formatted in a way that makes it tedious.
Extend the style sheet but I am not sure where to do this for the admin.
Create a custom.css but could not figure out where to put the path
Thanks for your advice!
It seems to me like Compass is just a tool to write CSS. I've never used it, but at the moment I don't see how it could make modding the admin interface any easier than doing it manually!
Whenever I make changes to the admin (I've made changes to Grappelli, like you're trying to do), I always use what you've listed as number 2. I've never had any troubles! I can try to help you out, if you'd like to try again.
What I do first is go to my Python install directory and copy the Grappelli source from Lib/site-packages. I put this code in my project directory as a project-level app. So, if you're using Django 1.4, you'll have a folder that has your project folder as well as manage.py in it. Put the code there.
Then, using your favorite web developer tools (I prefer Chrome's), figure out which stylesheet you need to modify and which css file it's in. I do this by right-clicking the element and selecting Inspect Element. This brings up the dev tools, and at the right it tells you the css file its referenced from as well as which line its on. If you open up that css file in your favorite text editor and make changes to it, it should work!
Let me know if you're having any trouble with this. I can try to help you out further.
(and, P.S., I wasn't trying to be pedantic with a basic overview of the use of Chrome's developer tools. I was just trying to be helpful by not assuming anything. I hope you don't take it as an insult.)