I want to reverse engineer the Meteor example app "LocalMarket" and make something with a similar design for a different niche. The problem I'm having is I almost don't even know where to begin, for changing the navigation.
According to the official Meteor tutorial, when we create our meteor app it creates a folder with a .js file, an .html file, a .css file, and a .meteor folder.
But the LocalMarket app has the .meteor folder and then several other folders:
client, cordova-build-override, lib, public, resources, server.
There's also a mobile-config javascript file and a readme doc.
I (sort of) don't understand why there are separate folders for client and server and so many different style sheets. But that's kind of beside the point.
Long story short (and you have to run the app with Meteor to see what I mean for this question): I want to change the navigation text, icons, and links: Home, What's Cooking, Recipes, Bookmarks, About, while keeping that awesome menu style and probably just modifying the existing pages to avoid having to rename everything. Though if you have suggestions for easily renaming the pages I'm all for it.
In templates\app-body.html it looks like the menu structure is defined. For example
<a href="{{pathFor 'about'}}" class="{{activePage 'about'}}">
<span class="wrapper-menu-item">
<span class="icon-question"></span>
<span class="title-menu">About</span>
</span>
</a>
links to the Bookmarks page.
But I am not finding the styling for any of the classes listed, except in a "merged-stylesheets.css" document in .meteor\local\build\programs.
Is it okay to modify merged-stylesheets.css though? I thought the .meteor folder was not for app developers to modify. Am I wrong about that?
I do see the classes in there, i.e.:
icon-question:before {
content: "\e613";
but I am not finding that "e613" reference anywhere.
Any insight on changing out the navigation icons, text, and links for the different pages in the LocalMarket example app based on the specific issues I've mentioned, would be appreciated.
Any ways to change the page titles, and change everything app-wide to reflect that, without fatally destroying the new app, would be super appreciated.
I see how to modify the content on the pages. That looks pretty straightforward.
A way to change the displayed titles of the pages without changing their classes/ functional references to them in other app files, would help too.
Thanks very much!
There are many questions in there, hopefully we can answer most of them.
Stuff in /server is only visible server-side.
Stuff in /client is only visible on the client.
Stuff in other top level directories (and their subdirectories) is visible to both server and client
Stuff under .meteor should not be changed. That's where all your packages end up
It sounds like the style sheet for the example is part of a package. That means you shouldn't edit it directly but should instead override the styles you need to change in your own .css file that you create under /client. Your style sheet(s) will load after any package style sheets which means your styles will win.
It also sounds like one of the packages installs its own icons, hence the "\e613" You can install your own icons too using (for example) fontello
I don't know where the page titles are set in that example. There's probably a head.html file with a <title> tag or it could be set in the router.
Related
I'm using webpack to bundle my project and I want to load the style in my web component template as an external link, so that I can make use of browser caching.
It works well when I'm loading the CSS inline, but I want to avoid doing that, as I feel it is not the best to repeat the large amount of CSS inside the same page.
I have tried the below steps
Keep the CSS name static - works, but not a feasible solution as it doesn't help with the cache bursting
Tried exposing the dynamically generated file name as global constant via webpack. it does not work :(
new webpack.DefinePlugin({PUBLIC_CSS_FILE: JSON.stringify('css/[name].[hash].css'))}
Link to the sample code -> https://github.com/nmakod/web-component
Any suggestions will be greatly helpful
I am not new to React philosophy, and have been reading and paying attention to the community for quite some time now, but would still consider myself a beginner when it comes to actually building something. Therefore, I have decided as a little hobby project I need to actually just start building something instead of reading countless articles on how it's done.
I have no clue what the actual application is going to do yet, but what I have built now is good enough to ask my pressing questions on how to structure it with best current practices in mind.
Current app structure
Right now, this is the current layout structure of my application.
As of right now, I downloaded a starter template that already had a webpack config written for me, so for now, I would ignore the assets folder within the "src" folder, since I am not even using it to serve my css and images. Those are being served from the dist folder, which I know is not the right way to do it, but hey I can only do so much at once.
The Important Stuff
What I need most help with from you guys is the actual structuring of my components. I have been reading that CSS Modules is a good way to go, so I was looking to do something like that.
How The App Currently Works
Index.js contains the routing information. I am using React Router.
App.js is the main component for the application.
As you can see, my navbar component sits alongside the App.js file, as I plan to add a footer component there as well. Those two components are global across the entire app, and will always be in the same place in the browser. (Not sure if that's good practice.)
Inside of App.js, I render the navbar component, and include {this.props.children} which just renders content from React Router.
From there, I basically have created two other folders within the components folder, titled "landing" & "login". Those folders contain a main component, and then render other child components within them. I was thinking that each folder should get its own css file.
As I continue to build out app features and components, is this a good format to follow? Logistically speaking, I have no clue how to configure the css files to be served for each of these modules yet, but was hoping my theory of how it works is correct.
Wrap Up
Just to make sure I am being crystal clear, say for example I decide I want to build a dashboard component now. From what I just explained, my thought process would be to create a subfolder within the main components folder titled "dashboard", create a parent component for it, and then create several other child components. Then I would plop a .css file in there as well.
Here is a link to the github repo so you can see exactly how it's layed out.
Github Repo
Working version of the app
Apologize for the lengthy question, but I wanted to ensure I covered all of my concerns properly. Any other suggestions are very welcome.
There is no right or wrong answer or this one. You'll have to adapt to your project needs and notice what works best and what not.
In practice, some structures have proven to be quite useful:
Splitting by subject:
This generally means to have a folder for each 'type' or subject in your app. For example: components, utils, media and so on.
The components folder could contain other folders to group components together with their .css files, tests and other complementary code.
This structure especially fits a state handling framework like redux where you would probably want a folder for actions and action creators, a folder for reducers, a folder for store configuration and creating and so on..
Splitting by app-part
This means that you split your code in respect to logical parts of your app. Say you have a login form with a splash screen animation, all of those would be in a 'login' folder. If you have a user profile page with some dashboards then all of those and the components that they use will go into a 'user_profile' folder.
Do not torture yourself too much about are you doing this in the perfect way, because there is no perfect way. Just choose a reasonable structure the fits your project needs and go with it.
The important thing is to watch for the cases when your structure is breaking down. For example if you see that you are making changes in your application and you see that your current structure is making it difficult to refactor or to add features, or maybe it became too messy, then consider making changes to the way you structure your project.
I've started using SailsJS for a small web app and so far it's great.
However I'm struggling with the assets and layout.
Basically I would like to be able to use different type of assets (groups of css files) depending on the page.
For this, I wrote 2 different layouts, each should includes the correct css files.
However, when I add those files in the config/assets.js files there all bundled together.
Is there a way to specifiy in my layout which assets i want to use ?
I know you can specify assets.js or assets.styles but I would like to be able to create my own group .
I also tried to put those assets in a different directory (public for example) and load them manually in my layout. It's still not working because the server doesn't want to 'serve' them.
Any idea ?
Glad you're liking Sails :)
For now, you can (a) bring in all styles all the time and make only the relevant ones apply (b) use another tool (like Grunt) to bundle assets like you would in a vanilla node.js project or (c) link the stylesheets manually (put them in your public folder).
As for the roadmap-- the community is working on more options for serving templates/styles/client-side logic. There's an open spec here:
https://github.com/balderdashy/sails/issues/240
Hope that helps!
I know this is old, but in case anyone else comes across this; in recent versions of sails the asset pipeline is built around grunt by default (I haven't used sails before 0.10.x).
You can add your own exports in tasks/pipeline.js and link those to the appropriate location in tasks/config/sails-linker.js. E.g. you could have a views/public folder and tell sails-linker to inject publicCSS vars there. Then adjust your layout.ejs so that it imports the styles/javascript from whichever folder.
I am creating a site that uses Java Script and CSS from jQuery and jQuery Mobile. Right now I am not hosting any of the files but rather referencing URLs on the jQuery site. This has the disadvantage that I have to load resources from jQuery every time the page loads and I cannot alter the files myself. I want to switch to hosting this stuff locally and would like to go about it in an organized and scalalable fashion. Is there any better way to do this than just copying the code from the links and pasting it into my own local .css and .js files?
Modifying the jQuery source is not ideal as you would be required to maintain it with every new release. If there is additional functionality you would like to add, it is better to create jQuery plugins. As for managing your project with respect to CSS and JavaScript files, most IDEs will generate a series of folders following the convention of JavaScript and CSS files being placed in a scripts and styles directory, respectively, under your project root. On top of this, it is wise to catalog your changes with some form of source control, such as git. There is plenty of documentation on the web on how to use this tool, and explaining how to use any form of source control is far too broad for an answer on StackOverflow. There is a certain level of mental discipline you must maintain, however, especially if you are manually managing the structure of your web project. This will come with time and experience as to what works best for you.
Nowadays, we have tons of Javascript libraries per page in addition to the Javascript files we write ourselves. How do you manage them all? How do you minify them in an organized way?
Organization
All of my scripts are maintained in a directory structure that I follow whenever I work on a site. The directory structure normally goes something like this:
+--root
|--javascript
|--lib
|--prototype.js
|--scriptaculous
|--scriptaculous.js
|--effects.js
|--..
|--myOwnScript.js
|--myOwnScript2.js
If, on the off chance, that I'm working on a team uses an inordinate amount of scripts, then I'll normally create a custom directory in which we'll organize scripts by relationship. This doesn't happen terribly often, though.
Compression
Though there are a lot of different compressors and obfuscators out there, I always come back to YUI Compressor.
Inclusion
Unless a site is using some form of a master page, CMS, or something that dictates what can be included on a page beyond my control, I only included the scripts necessarily for the given page just for the small performance sake. If a page doesn't require any script, there will be no script inclusions on that page.
First of all, YUI Compressor.
Keeping them organized is up to you, but most groups that I've seen have just come up with a convention that makes sense for their application.
It's generally optimal to package up your files in such a way that you have a small handful of packages which can be included on any given page for optimal caching.
You also might consider dividing your javascript up into segments that are easy to share across the team.
Cal Henderson (of Flickr fame) wrote Serving JavaScript Fast a while back. It covers asset delivery, not organization, but it might answer some of your questions.
Here are the bullet points:
Yes, you ought to concatenate JavaScript files in production to minimize the number of HTTP requests.
BUT you might not want to concatenate into one giant file; you might want to break it into logical pieces and spread the transfer cost over several pages.
gzip compression is good, but you shouldn't serve gzipped assets to IE <= 6, so you might also want to minify/compress your JavaScript.
I'll add a few bullet points of my own:
You ought to come up with a solution that works for both development and production. In development mode, it should pull in extra JavaScript files on demand; in production it should bundle everything ahead of time. Switching from one behavior to the other should be as easy as setting a flag.
Rails 2.0 handles all this through an asset cache; other web app frameworks might offer similar solutions.
As another answer suggests, placing third-party libraries in a lib directory is a good start. You can also divide your own JS files into sub-directories if it makes sense. Ideally, you'll be able to arrange them in such a way that the files in a given sub-directory can be concatenated into one file.
I will have a folder for all javascript, and a sub folder of that for 3rd party/shared libraries, and sub folders for each component of the site to keep everything organized.
For example:
/
+--/javascript/
+-- lib/
+-- admin/
+-- compnent1/
+-- compnent2/
Then run everything through a minifier/obfuscator during the build process.
I'v been using this lately:
http://code.google.com/apis/ajaxlibs/
And then have a "jscripts" folder where I keep my custom code.
In my last project, we had three kinds of JS files, all of them inside a JS folder.
Library code. A bunch of functions used on most all of the pages, so they were put together in one or a few files.
Classes. These had their own files, organized in folders as needed, but not necessarily so.
Ad hoc JS. Code that was specific to that page. These were saved in files that had the same name as the JSP pages they were supposed to run in.
The biggest effort was in having most of the code on the first two kinds, having custom code only know what to call, and when.
This might be a different approach than what you're looking for, but I've been playing around with the idea of JavaScript templates in our blog engine. In a nutshell, you assign a Javascript template to a page id using the database and it will dynamically include and minify all the JavaScript files associated with that template and create a file in a server-side cache with the template id as a file name. When a page is loaded, it calls the template file which first checks if the file exists in the cache and loads it if it does. If it doesn't exist, it creates it on the fly and includes it. I also use the template file to gzip the conglomerate JavaScript file.
The template idea would work well for site-wide JavaScript (like a JavaScript library), but it doesn't cover page-specific JavaScript. However, you can still use the same approach for page specific JavaScript by including a second file that does the same as above.