TypeScripterSteve
New Coder
I have been using JavaScript since it was first created in the 90s.
(Tangent: I was late getting into TypeScript, but what a contrast...major reduction in dev time, sounder code! But using TypeScript now creates another level of code organization with a 'tsconfig.json' file, and how the VSCode IDE looks for the pieces of code it needs to do builds.)
In those earlier days, the scope for name resolution was pretty much global and function or block in the "browser"/"client-side" "environment". No "modular" code with
With server-side Node.JS execution, we can now develop and test with Node.JS before deploying to the browser (is that the better way/approach?) even if deployment is not on Node.
But from what ChatGPT3.5/Bard/Gemini/CoPilot tell me, references to names (variables, functions, classes, etc) between files (file scope) now have to be done using
What I have is a web app. The project folder contains files 'app1.ts', 'app2.ts',... in './src' subfolder. I have two dependencies: basically snippet code in a "general library", say 'genlib1.ts' and 'genlib2.ts' and "true modular library" or "framework" (say, SPREST, for doing REST requests/responses for SharePoint) like 'splist.ts' and 'spuser.ts'.
In my small example below, I show interaction between three files: 'app1.ts', 'app2.ts', and 'splist.ts'. At the top of all files are
This is how it's done, right? I am not missing or misunderstanding anything, right?
If the answer is in a web article, even a book, and you just cite it or say "go read this", I appreciate being steered in that direction.
(Tangent: I was late getting into TypeScript, but what a contrast...major reduction in dev time, sounder code! But using TypeScript now creates another level of code organization with a 'tsconfig.json' file, and how the VSCode IDE looks for the pieces of code it needs to do builds.)
In those earlier days, the scope for name resolution was pretty much global and function or block in the "browser"/"client-side" "environment". No "modular" code with
import
/export
statements in that era. No modifying <script> elements with the type
attribute value 'module'.With server-side Node.JS execution, we can now develop and test with Node.JS before deploying to the browser (is that the better way/approach?) even if deployment is not on Node.
But from what ChatGPT3.5/Bard/Gemini/CoPilot tell me, references to names (variables, functions, classes, etc) between files (file scope) now have to be done using
import
and export
statements. It seems a 'module' is not set of files providing feature/functionality, but rather the individual file itself.What I have is a web app. The project folder contains files 'app1.ts', 'app2.ts',... in './src' subfolder. I have two dependencies: basically snippet code in a "general library", say 'genlib1.ts' and 'genlib2.ts' and "true modular library" or "framework" (say, SPREST, for doing REST requests/responses for SharePoint) like 'splist.ts' and 'spuser.ts'.
In my small example below, I show interaction between three files: 'app1.ts', 'app2.ts', and 'splist.ts'. At the top of all files are
import
and export
statements with each between-file interaction. In reality, I have each file that will have import
and export
statements with several comma-separated braced names (variables, functions, etc).This is how it's done, right? I am not missing or misunderstanding anything, right?
If the answer is in a web article, even a book, and you just cite it or say "go read this", I appreciate being steered in that direction.
Code:
app1.ts
import { displayUser } from './app2';
import { ItemData, SPList } from '../../SPRESTLib/src/splist';
function initialize() {
const userList = new SPList();
}
Code:
app2.ts
export { displayUser };
function displayUser(userInfo: ) {
// code to display user to web page part
}
Code:
splist.ts
export {
SPList, // class
ItemData // list item data type
};
class SPList {
constructor() {
// create & initialize a list
}
addItem (itemData: ItemData): itemId {
let itemId: number;
// code to add (create) item to list
return itemId;
}
deleteItem (itemId) {
// use ID to find item in list, then delete it
}
}