I'm starting with Express and TypeScript and I would like to know how is the folder structure to define the types in large projects.
For example, in Java projects, models and dto folders are usually created to define their entire structure. Can I follow this same structure in TypeScript or is there a better way?
I have searched and I see that a type.d.ts, type.ts or emun.ts file is usually created, others put users.interface.ts and it groups the entire structure here.
Related
We are starting a new project using angular2, typescript and gulp. For the time being our application will consist of two subprojects: a components library (which in the future might be spun off into a separate project) and the app using the component library.
The layouts of the project is going to be something along the lines:
/project_root
/component_library
/src
/library
/components
/services
... etc
/application
/src
/app_name
/components
/services
... etc
The components in application will be using components from the library (but not the other way round)
We would like to have clean (non relative) imports in the app components when importing stuff from the library (we want to avoid ugly imports of the sort '../../../component_library/src/library ...etc' plus, what's more important, we want to be able to move the library code to a separate project without the need to update imports.
There are two possible solutions I see (don't like any of them):
Add a gulp task that would watch the component library and on every change copy the file to node_modules in /project_root
Some sort of simlink? so that we can point /project_root/node_modules to /project_root/component_library/src?
I'm afraid the first solution might not work well with IDE autocomplete in the application (first gulp would need to do the compilation/copying then the IDE would need to pick up the change from node_modules - this looks like something that can be really slow)
The second solution feels hacky - it would need to be repeated by everyone who checks out the code from repo.
What would be the best solution here?
what's more important, we want to be able to move the library code to a separate project without the need to update imports.
Ship your component_library with source and add it as a node_module dependency. Then when someone pulls your code they can add a git remote to node_modules/component_library code and work on the two projects seemlessly.
This is the approach I took with ntypescript.
Good day,
I just started with EmberJS in combination with Ember-Runner. I found an working example on Github.
Ember-runner automaticly adds all your template files and JS (at least that is what I thought) together and generarates a singe HTML / JS / templates / CSS file from your own files every time you save. (And optionally minify's and such). A build tool, just like it says in the description.
This is what it does for the CSS and templates part, however for the JS part it only seems to include only one file in my JS folder which is called 'main.js'. Is it possible to scan that dir for other files so it includes those as well? (So I can have separate controller / model files and such).
I hope my question is clear.
Kind regards,
Matthijn Dijkstra
I'm looking for something similar conceptually to a Windows DLL. As a concrete example, suppose I have a function encrypt that I would like to share across several unrelated projects. If I want to change the implementation ideally I can do so once and every project has access to the new implementation. Is there a mechanism for doing this in Node.js?
Have a look at this document especially the section "Writing a Library"
If you are writing a program that is intended to be used by others,
then the most important thing to specify in your package.json file is
the main module. This is the module that is the entry point to your
program.
and
If you have a lot of JavaScript code, then the custom is to put it in
the ./lib folder in your project.
Specify a main module in your package.json file. This is the module
that your users will load when they do require('your-library'). This
module should ideally expose all of the functionality in your library.
If you want your users to be able to load sub-modules from the "guts"
of your library, then they'll need to specify the full path to them.
That is a lot of work to document! It's better and more future-proof
to simply specify a main module, and then, if necessary, have ways to
dynamically load what they need.
For example, you might have a flip library that is a collection of
widget objects, defined by files in the flip/lib/widgets/*.js files.
Rather than having your users do require('flip/lib/widgets/blerg.js')
to get the blerg widget, it's better to have something like:
require('flip').loadWidget('blerg').
Kohana 3.2 was designed to support the HMVC design pattern. The HMVC pattern consists of nested MVC-triads. Yet as far as I can tell, Kohana's cascading file system requires all Models and Controllers to be placed within a top 'classes' directory, and Views into a top 'views' directory. If Model/Controllers are thus separated from Views at the top level of the file system, then how are we supposed to implement nested MVC-triads?
Not sure if you'd want to hack the way that views are processed, but you can extend the Kohana_View class so that set_filename() function will accept any directory that you want.
If you want an auto-loading feature similar to controllers / models, you could implement it yourself.
For example (untested):
public function set_filename($view)
{
// Transform the class name into a path
$file = str_replace('_', '/', strtolower($view));
if ($path = Kohana::find_file('classes', $file))
{
// Store the file path locally
$this->_file = $path;
return $this;
}
throw new View_Exception('The requested view :view could not be found', array(
':view' => $view,
));
}
Yet as far as I can tell, Kohana's cascading file system requires all Models and Controllers to be placed within a top 'classes' directory, and Views into a top 'views' directory.
What you seem to want is a folder structure like Kohana 2, codeigniter and most likely other frameworks, which have dedicated folders for controllers, models, and views. Kohana 3 has a dedicated folder for classes. The way Kohana 3 is built enforces that controllers should have a Controller_ prefix. The Kohana 3 autoloader will look for classes with a Controller_ prefix in the classes/controller folder.
Then Kohana 3 also comes with very basic Model and View classes. The Kohana 3 core does not use the Model class as far as I am aware and it uses the View class only on a few occasions. But the convention to give models the Model_ prefix can be found in Model::factory(), it is not enforced however. You do not have to use them.
The View class looks for templates in de views folder. The (not recommended by Zombor) View_Module by Zombor (one of the devs) also happends to look there. The (redommended by Zombor) KOstache module, again by Zombor, looks for its templates in the templates folder. Both modules let you create View-Model classes for which the convention is to have the View_ prefix so they end up in classes/view. But nothing stops you from creating a View_ class which extends View for every template you put into the views folder and hardcode the path for that View-Model.
Please respect that the classes folder is only for classes.
When generating my DAL files with SubSonic, I'd like the names of the files to be .gen.cs. The main reason for this is that the files are partial classes, and I would like to add some additional implementation details into another source file for the table called .cs. This is somewhat the standard pattern for generated source files , and I'm wondering if its possible with SubSonic? I'm using SubSonic 2.2.
I thought you might be able to do this by using a set of custom templates, but the CS_ClassTemplate.aspx (or VB_ClassTemplate.aspx) doesn't control the file name of the class.
I don't think this is possible.
As an alternative, you can do what I do. I have a "generated" directory, such as \database\generated and then I put my partial classes at \database\custom. As long as the namespaces of the files in the two different directories match (like .database or whatever), then it works fine. By using two different directories, it's easier to find your custom files without looking at the generated ones.