I've created a web page that's for all intents and purposes, a style guide for other developers working on our application.
I have my .scss files within the _sass directory in my Jekyll project, and it's created all the CSS files beautifully. On my page however I want to display the code from these .scss files in the page within some <pre><code> tags.
Currently I have the code in here repeated in both places. When it was quite small it wasn't such a problem, but now it's got bigger it needs DRY-ing out.
I first went down the path of using Jekyll's {% include [path/to/file] %}, and then realised that only works for stuff in the _includes folder, and I couldn't use the include_relative option either as the _sass folder isn't a child of the location it's used.
Secondly I tried using the angular approach, as I'm already using it in my application. Threw in some <pre><code ng-include="'../_sass/components/_sflButton.scss'"> and expected it to work. Of course, it didn't because the _sass folder isn't generated into the actual site when you run it. And I can't seem to find a way of getting it to include it. Tried changing a few things in _config.yml to no avail.
So, TL;DR, I want to either be able to include the code from my _sass folder onto my page via Jekyll, or find a way of getting the _sass folder to be loaded into the generated site so I can load it in with Angular. Am I trying to do an impossible task here? Willing to listen to any suggestions that mean the code is only written in one place.
The theory behind getting this done is as follows:
_sass is a special directory for Jekyll (similar to _layouts, _includes) that is handled differently in comparison to other directories you create. Its contents are not output to the destination directory.
you can write simple ruby programs and add them to a directory called _plugins and Jekyll will run those custom programs during the build process. (Ignored by GitHub Pages).
Now write a ruby program to "read" the contents of _sass and have the resulting data be formatted as a hash and have this hash fed to existing site_payload
The hash can be additionally passed as a Drop instance to have the data available via the Liquid templates.
I concede this answer doesn't actually solve your problem esp., if you're not familiar with Ruby, and Jekyll codebase. but it'll serve as a starting point..
Related
I am now working on a react ecommerce website and I have encountered an issue that I forgot to give keys to the lists I rendered. So, I was wondering if there is a way to see one file which contains all the code for that web app, like in Sass , we write code in different files but we are able to see the massive file that contains all the code that we wrote across multiple files.Even if we can't change that file, it would be nice to see how many lines of code are there. So ,is there a way to do that?
I have had a developer create a website or app in React. This is already on a webserver and does what it should do. Now I want to develop the frontend myself, which would be no problem if I knew how to edit the code.
On the server I have an index.html, some stuff like favicon and a folder. This folder contains the folders "css", "js" & "media" and I don't understand their content. In the folder "css" are for example the files "main.12345.chunk.css" and "main.12345.chunk.css.map" Both look very cryptic.
Now I found out after some research that this is probably a compressed representation. Possibly compressed with Webpack?
But how can I edit these files in a meaningful way and understand what was coded there in the first place? Normally I would just download the file to be changed with Filezilla and edit it with an editor or Visual Studio code, but in this case I have no idea.
Those "cryptic" files are probably minified. Minification is a process where the original code is minified using several approaches, making it much smaller in size and also sometimes better performing. This is done by Webpack with a build process.
Those files are not meant to be develop with (or even read for that matter). Their sole purpose is to be optimized and be run in a production environment. It's very hard or even impossible to understand those, you would basically have to reverse-engineer them to understand what's going on. Many websites actually use minification for this additional bonus of protection of their application logic, because minimization basically obfuscates client side code. For example, the WhatsApp web client written in React is heavily obfuscated, in order to not allow anyone to write a WhatsApp client (there are efforts for this particular example, but it takes lots of time).
TL;DR: You have to get the original source files in order to edit them.
But how can I edit these files in a meaningful way and understand what was coded there in the first place?
They really are not designed for editing.
Edit the original source code to the application, then run its build script and deploy the output from it.
I am trying to make a folder to be not watched. Is there a way to make one of the folders not watched in Meteor? I don't want my project to reload if I change a content in that folder.
Not exactly. Meteor assumes that if the folder content changes, it also needs to reload/restart the server, because the business logic of the application might have changed. Therefore it reloads these files and restarts the server
However, you might be able to "abuse" the tests/ directory or any of the directories/files mentioned below for that purpose. As explained in the Meteor guide on Application Structure, paragraph "Special directories":
Any directory named tests/ is not loaded anywhere. Use this for any test code you want to run using a test runner outside of Meteor’s built-in test tools.
The following directories are also not loaded as part of your app code:
Files/directories whose names start with a dot, like .meteor and .git
packages/: Used for local packages
cordova-build-override/: Used for advanced mobile build customizations
programs: For legacy reasons
So the reasonable choice would be to create a dot directory, e.g. .myStuff, and place anything that you might need to update but do not want to trigger a server restart there.
Just build your app in a package so you can decide which files you want to make available or not :)
I have a web-app(browser based) which needs to access a folder full of icons that resides outside the web folder.
This folder MUST be outside the web folder, and would ideally exist outside the project folder all together
however, when specifying the path to the folder neither "../" or making use of a symlink will work
when the page attempts to load the image I always get
"[web] GET /Project|web/icons/img.png => Could not find asset Project|web/icons/img.png."
however I set the image source to "../icons/img.png"
how can i get dart to access this file properly
PS: I attempted a symlink to another part of the filesystem (where the images would be kept ideally) however this did not work either.
The web server integrated into DartEditor or pub serve only serves directories that are added as folders to the files view. When you add the folder to DartEditor you should be able to access the files. This is just for development.
You have also to find a solution for when you deploy your server app. It would be a hazardous security issue when you could access files outside the project directory. Where should the server draw the line? If this would be possible your entire server would be accessible to the world.
Like #Robert asked, I also have a hard time imaging why the files must not be in the project folder.
If you want to reuse the icons/images between different projects you could create a resource package that contains only those images and add them as a dependency to your project.
If you want a better answer you need to provide more information about your requirements.
If you wrote your own server (by using the HttpServer class) it may be possible to use the VirtualDirectory to server your external files.
Looking at look the dartiverse_search example may give you some ideas.
You could put them in the lib directory and refer to them via /packages/Project/...
Or in another package, in which case they would be in a different place in the file system. But as other people have said, your requirement seems odd.
I would like to know your opinion about how you would organize the files/directores in a big web application using MVC (backbone for example).
I would make the following ( * ). Please tell me your opinion.
( * )
js
js/models/myModel.js
js/collections/myCollection.js
js/views/myView.js
spec/model/myModel.spec.js
spec/collections/myCollection.spec.js
spec/views/myView.spec.js
This is how I've traditionally organized my files. However, I've found that with larger applications it really becomes a pain to keep everything organized, named uniquely, etc. A 'new' way that I've been going about it is organizing my files by feature rather than type. So, for example:
js/feature1/someView.js
js/feature1/someController.js
js/feature1/someTemplate.html
js/feature1/someModel.js
But, oftentimes there are global "things" that you need, like the "user" or a collection of locations that the user has built. So:
js/application/model/user.js
js/application/collection/location.js
This pattern was suggested to me because then you can work on feature sets, package and deploy them using requirejs with relatively little effort. It also reduces the possibility of dependencies occurring between feature sets, so if you want to remove a feature or update it with brand new code, you can just replace a folder of 'stuff' rather than hunting for every file. Also, in IDE's, it just makes the files you're working on easier to find.
My two cents.
Edit: What about the spec files?
A few thoughts - you'll just have to pick the one that seems most natural to you I think.
You could follow the same 'feature folder' pattern with the spec files. The upside being that all of the specs are in one place. The downside is that now, much like what you're currently doing, you have to places for one feature's files.
You could put the specs in a 'spec' folder of the feature folder. The upside is that you now have actual packages that can be wrapped up in a single zip file with no chance of clobbering other work. It's also easier to find directly related files for writing tests - they're all in the same parent folder. The downside is that now your production code and test code is in the same folder, publishing it (possibly) to the world. Granted you'll probably end up compiling the production javascript down to one file at some point.. so I'm not sure that's much of an issue.
My suggestion - if this is a large application and you figure you're going to have a few hands touching the files, leave something like a 'package.json/yml/xml' file in the folder. In there, list out the production, spec, and any data files you need for testing (you can most likely write a quick shell script to do this for you). Then write out a quick script to look through your source folder for 'package.whateverYouChose' files, get the test files and then build your unit testing page with it. So, let's say you add another package.. run 'updateSpecRunner' or whatever you name the script, and it'll generate you another SpecRunner.html file (or whatever you named the file your running the specs on). Then you can manually test it in a browser, or automate it using phantomjs/rhino.
Does that make sense?
You can find a good example how to organize your application to this link
Backbone Jasmine examples
It looks more or less like your implementation.