Developer Docs - Obsidian - App Laws

Naming Conventions

Components

Formatting and Styling

We know some of these styling/formatting options are different than C# styles. These are more inline with default/expected JavaScript and TypeScript formatting.

ESLint will enforce most of the rules for you so make sure to enable it in your development environment.

Deprecation

To deprecate or obsolete something, use the `@deprecated` JSDoc tag. It should follow this pattern: @deprecated since version 18.0. [optional text to describe alternative.

/*
 * Some old functionality.
 *
 * @deprecated since version 18.0. Use the newFunctionality() function instead.
 */
function oldFunctionality(): void {
} 

Package and References

Just like C# has "using" statements to allow you to reference information in another namespace or assembly, TypeScript has an "import" statement that behaves in a similar way.

The primary difference is that in C# everything has a namespace. But TypeScript doesn't use namespaces in this way. Instead, the file system structure is what it uses to organize information.

Another difference is that TypeScript doesn't have assemblies. A similar concept is packages. Packages are referenced the same way as any other import statement in TypeScript, you just start your path reference with the package name.

For example, import ... from "linqjs/list" means you are referring to the "linqjs" package and want the "list" file inside of it.

Because Obsidian is such a large framework, we have divided it into multiple packages:

Each package contains only objects that are related to that package. For example, there should be no field types declared in the @Obsidian/Controls package.

There is also a dependency structure associated with all these packages. Because cyclical dependencies are not allowed, you must be careful to put new objects in the correct package. Meaning, if Utility package references the Controls package, the Controls package cannot (even indirectly) reference the Utility package.

The dependency tree for these packages looks like this. The arrow points towards the dependency, meaning the arrowhead is attached to the package that is depended on by the tail.

As a Block developer, you are safe to use any of those packages. If you are adding something to the core framework, you need to follow this dependency tree. So if you are adding a new Control, you can use something that is in the ValidationRules package. But not the other way around. Basically, you can use anything further up the tree from where you are currently.