I have a bit of a strange (but in my view sensible) scenario.
I have a web site, mobile application and maybe going forward a web server all written in Javascript. I have a huge chunk of functionality which is shared between all these systems. This shared stuff would be models, repositories, business logic etc etc.
If we exclude the web server bit as that is a future idea, the web application has a directory structure like this:
app
|- assets
|- models
|- services
|- migrations
|- view-models
|- views
|- descriptors
Now each of these applications is broken down into 2 areas, the core and ui sections, the core is the re-usable stuff such as models, services, migrations and the ui stuff is ONLY used for that application which would comprise of view-models, descriptors (Incase you are wondering views are all html and assets are css, images etc).
Before I was adopting typescript I had a build script which would basically combine all the core files together and minify them. Then it would combine all the UI ones together and minify them. That way in the mobile application I can then just use the my-app.core.min.js and everyone is happy, I am reusing all the re-usable components from the main web application. However I do not need the ui stuff as the mobile UI is completely different to the main web ui, and the web service would not even have a UI going forward.
SO!
With that context explained lets jump back to the Typescript problem at hand. Currently the typescript files are compiled by tsc.exe (version 0.83) via a build script, which just wraps the interaction.
So in the new Typescript world the structure now has a references folder like so:
app
|- assets
|- models
|- services
|- migrations
|- view-models
|- views
|- descriptors
|- references <- NEW ONE!
This references folder is automatically populated by the build script with all local references, so it will trawl through the whole directory tree find all typescript files and build a huge reference file, which is a file full of the reference declarations for local typescript file, to find out more about what im on about look over this question:
Can you create Typescript packages? like c# dlls
So now when I run the build script the following steps happen:
Compiling for Core
Find all *.ts files within the models, services, migrations folders and subfolders
Add all the previous files into an array and also add in the reference files
run tsc.exe with a command like so tsc.exe --out <something>.core.js <previous_file_list>
Compiling for UI
Find all *.ts files within the view-models, descriptors folders and subfolders
Add all the previous files into an array and also add in the reference files
run tsc.exe with a command like so tsc.exe --out <something>.ui.js <previous_file_list>
Now I was expecting this to output 2 files my-app.core.js which ONLY contained the core files, and a my-app.ui.js which ONLY contained the ui files. However they both include everything...
Now after thinking about this, it must be due to the references, as they are both referencing all files, however thats just a compilation dependency in my eyes, not something that needs to be compiled WITH the outputted javascript. In c#/java you would not expect a referenced dll/jar to be compiled into your outputted dll/jar, its just a runtime dependency which is required.
I have tried having 2 separate reference files, one for core and one for ui, but as the ui will depend on core I get same problem, although at least this way the my-app.core.js is devoid of any ui related guff.
So is there a way to have references but NOT have them be outputted into the generated javascript files?
You can accomplish this by generating definition files for your TypeScript files:
tsc --declaration FileName.ts
In your build script do this for each TypeScript file and use the generated FileName.d.ts as the reference instead of FileName.ts
I had the following files:
-BusinessObjects
--Product.ts
--Customer.ts
--Order.ts
--BusinessObjects.d.ts
BusinessObjects.d.ts looks like this:
/// <reference path="Customer.d.ts" />
/// <reference path="Order.d.ts" />
/// <reference path="Product.d.ts" />
with Product, Customer, and Order each have a reference to BusinessObjects.d.ts
when I run:
tsc --out combine.js Customer.ts Order.ts
The output only references Customer and Order, Product is not included. When I referenced the *.ts files directly in my BusinessObjects.d.ts file however the combined output did include the unwanted file.
Related
I'm currently using Meteor and trying to learn more about the framework. In the documentation about special directories the following is said about the public/ special directory:
All files inside a top-level directory called public/ are served as-is to the client. When referencing these assets, do not include public/ in the URL, write the URL as if they were all in the top level. For example, reference public/bg.png as <img src='/bg.png' />. This is the best place for favicon.ico, robots.txt, and similar files.
My question is: since I refer to files inside of public/ directory as if they were located in the root folder of my application, what's the different between putting the files in the public/ folder and in the root folder? Or is it just for organization sake?
Also the documentation I quoted above makes some examples using assets (some pngs and favicon.ico) and no JavaScript or HTML files. Am I able to put some JavaScript code in there and then import them in another file by referencing as if this code was located in the root of my app? Or is the public/ directory somewhat made only for assets?
I failed to find any docs that explains what is done to files inside this directory in detail (I only found what I quoted above). So if any documentation of that kind is available it would help a lot!
My question is: since I refer to files inside of public/ directory as if they were located in the root folder of my application, what's the different between putting the files in the public/ folder and in the root folder? Or is it just for organization sake?
Just because you can reference or "import" a file from public/ doesn't mean it functions in the same way to how a normal file import would work. Files located in public gets served as is without being minified/run through the Meteor pipleline. Second, these files are accessible to the client which makes sense given how'd import them without preceding slashes and keep them mostly to serve stuff like favicon and what not.
So in a sense, such files within public are made available within relation to your client bundle/code whilst not being a part of them, get it?
This way of serving assets isn't unique to Meteor, even React has a public directory.
Also the documentation I quoted above makes some examples using assets (some pngs and favicon.ico) and no JavaScript or HTML files. Am I able to put some JavaScript code in there and then import them in another file by referencing as if this code was located in the root of my app? Or is the public/ directory somewhat made only for assets?
AFAIK, you can have files of any type in public but since
It's served as is to the client, meaning it's exposed to the public
It doesn't get minified (i.e being part of the final application build code)
You're advised to not have any of the application code within this directory.
The Public folder is how you serve your static files, when you put a file in your root folder it will not be sent to the client by default and you can't use it in your css, when you put that file (say an image) in your public folder you can use it from the css and refer to it as if it was in your root folder, so if I put a.jpg in the public folder I can use url(/a.jpg) in my css, that won't work if a.jpg is simply in your root folder, that's what the docs mean when they say it's served as if it was the root folder.
unlike in Rails, Meteor initiatives don’t have a rigid document structure and you are quite a whole lot free to prepare your projects as you want. a few folder names but have unique which means, and documents within them will be dealt with in a different way.
consumer
files here will be loaded at the client simplest. files in that folder don’t need things like Meteor.isClient.
server
Loaded on the server best, duh! No need for Meteor.isServer whilst files are in that folder, the client won’t see these files.
public
This directory is for property like photographs. on your initiatives, you reference stuff in the public folder as if they have been in the root folder. as an example, when you have a report: public/nude.jpg, then for your app you include it with .
personal
files only available at the server facet thru the assets API.
checks
documents in there received’t be loaded anywhere and are used for checking out your app.
lib
documents in that folder are loaded earlier than whatever else, which makes it the best listing to vicinity the distinct libraries used on a undertaking.
What is the correct way to structure files in real life application?
By default, if I'm correct, ASP.NET Core projects files should be structured as:
[Solution]
[Project]
Dependencies
Properties
Controllers
Models
Repositories
wwwroot
Pages
Startup.cs
Program.cs
appsettings.json
For any static file it should be inside a wwwroot folder, right?
But then why creating a ASP.NET Core project with React + redux template makes a folder 'ClientApp' instead of 'wwwroot' and places all react code in there with folders 'src' 'public'?
I know that you can do that and then in startup.cs enable it with 'app.UseSpaStaticFiles();', But why? Is it just to make it simpler or does it have real life benefits? Should I structure my files same way too?
And if I suppose, or can, use with 'wwwroot', how should wwwroot folder look? I know that wwwroot folder suppose to contain all the static files such as css, images and js
wwwroot
css
js
images
Since react is a js library/framework, should all code be inside js folder like this
wwwroot
css
js
src
actions
components
store
...
images
I been trying to find an answer but everywhere everyone has a different answer.
On a side note, also if using scss, or similar, should all the scss be inside css folder or should there be a scss folder inside wwwroot that on compile saves css code inside css folder?
I have a series of js files. (i.e. 0.js , 1.js, 2.js, 3.js ... 15.js) along with 0.js.map , 1.js.map ... 15.js.map in a folder that also contains main.js and main.js.map and vendor.js along with vendor.js.map.
These are files that contain Phonegap(Cordova) and Ionic code.
The project is probably using Angular for building. Although in the Chrome Dev Tools in the Sources tab I can only see the ng folder. A webpack folder does not seem to be displayed. According to https://angular.io/cli/build :
The application builder uses the webpack build tool, with default configuration options specified in the workspace configuration file (angular.json) or with a named alternative configuration.
Is there a way to convert the files in their original Typescript format using the source map files (.js.map) in order to alter them?
I'm trying to understand Meteor as I create a project and I find some things a little difficult to understand so far.
1- When they say I can create a server and a client folder, where exactly I am meant to do so? Sibling of .meteor ? And will everything be at client's or server's scope when the app starts or do I have to do something else? If I create a foo.js and a foo function inside it in client folder, can I just call foo() in Meteor.isClient and it will work?
2- I need to create an upload folder so people can upload their stuff (images). So where am I supposed to do this? Plus, how can I get the absolute path to my project and find this upload folder inside?
During my attempts I tried the following:
fs = Meteor.npmRequire('fs');
__ROOT_APP_PATH__ = fs.realpathSync('.');
But __ROOT_APP_PATH__ is .meteor\local\build\programs\server. Quite hidden right?!
3- I saw some people uploading and saving files on MongoDB directly. This is something we usually don't do with relational databases. We move the file to a known folder on a CDN or on our own disk and save the hash or name of that file so we can easily find it. Isn't it encouraged with Meteor + MongoDB? Why would I save the file itself on Mongo instead of moving it to a folder?
not any specific way to do but meteor recommend it doing this way
http://docs.meteor.com/#/basic/filestructure
FOLDER STRUCTURE:
both/ (OR lib/) -- common code for server and client
|- collections/ -- declare collections (e.g Employer = new Meteor.Collection("employer");)
|- router / -- router code(e.g Router.route(..))
client/ -- client side code
|- global/ -- all global variable for client
|- helpers/ -- global helper for client (for all templates)
|- plugins/ -- all the plugins code(if you use any)
|- stylesheets/ -- css / less files
|- templates/ -- all templates
|- home.html -- home template(html)
|- home.js -- home template(js)
public/ -- images/icons/fonts (meteor looking at this file)
server/ -- server code
|- methods/ -- server methods/API (e.g Meteor.methods({...}))
|- publish/ -- publish code from server
this is the basic folder structure for meteor project which i follow. For further reference or Documentation. For any question feel free ask in comments..
I searched over the internet but I could not find an answer to my question. I am just trying to figure out a clean way to structure my CSS and JS files inside my project. Let us say for example I have a CSS folder and I have a custom my.css file and also I have a Scripts folder and I have inside it a myscript.js. I understand that my.css will go in the CSS folder and myscript.js will go under the Scripts folder in this folder setup :
root
css
my.css
Scripts
myscript.js
My question is, if I want to use a jQuery plugin like jstree for example. This library require me to add one js and one css file. Should I keep these files under the Scripts and CSS folder ?
Plan A
root
css
my.css
jstree.css
Scripts
myscript.js
jstree.js
Or should I separate them into a different folder for cleaner structure like this
PLan B
root
css
jstreeFolder ---> jstree.css
my.css
Scripts
jstreFolder ---> jstree.js
myscript.js
Is this structure acceptable? Any standard ways for achieving this ?
Any help is appreciated.
Root
-- styles
|-- your_file.css
-- scripts
|-- your_file.js
-- libs (or plugins)
|-- jquery
|-- jquery-ui
...
I think this structure will be nicer and all the third party libraries (no matter css or javascript libs) that you've chosen should be located under libs directory. It will make maintenance be easier and clear.
For mainentance reasons i prefer another approach. The library jstreee organise the javascript files, css-files and images in a certain way.
/libs/
/jstree/ // <-- folder
/themes/ <-- folder
/default/ <-- folder
style.css
32px.png
jstree.js
jstree.search.js
/other-plugin/
I put everything under libs and in a folder with the name of the library. This way the external dependency of a library is clear and the internal path structure (css files may point to images) of the external library is untouched.