Lmst

#Development #Introductions
The killer feature of web components · A look at the Custom Elements Manifest initiative https://ilo.im/167mgm

_____
#WebComponents #TypeScript #JSDoc #JSON #API #WebDev #Frontend #HTML #CSS #JavaScript

@chriskirknielsen Quick idea : as #JSDoc seems highly similar to #PHPDoc and the original #Javadoc , you might have some luck with tools written for any of those as well.

Do any of you fellow nerds have a tool that parses (select) JS files for #JSDoc comments and spits out _something_ that can be used as-is or plugged into some kind of documentation template?

This project I'm on has about a zillion (well documented!) functions and I'd love to be able to share them with new team members. Instead of saying "uuuh yeah we have a timezone-stripping date function _somewhere_…", it would just be like "look up the docs, search for ‘date’" and presto badabingo. Thanks!

Despite a few annoyances with JSDoc for adding types, I think it's great. The habit of adding comments and descriptions has proven to be incredibly useful.
I noticed that my CSS code isn't as nicely commented. Maybe I should give KSS another look?
#css #webdev #jsdoc #javascript

Документирование фронтенд-приложений: обзор JSDoc и Storybook

В современной веб-разработке качественная документация так же важна, как и качественный код. Когда ваше приложение разрастается до десятков или сотен компонентов, функций и модулей, становится практически невозможно удерживать в памяти все детали их работы. Хорошая документация не только облегчает поддержку проекта в долгосрочной перспективе, но и значительно ускоряет вхождение новых разработчиков в команду. В этой статье мы рассмотрим два популярных подхода к документированию фронтенд-кода: JSDoc и Storybook. Они решают схожие задачи, но совершенно разными способами и с разным фокусом.

https://habr.com/ru/articles/905996/

#jsdoc #storybook #приложения #фронтент #документация

How JSDoc Saved My Dev Workflow, by (not on Mastodon or Bluesky):

https://spin.atomicobject.com/how-jsdoc-saved-my-dev-workflow/

#jsdoc #javascript #typescript #documentation

Anyone know how to tell #JSDoc which #ECMAScript version to use?
I want to use Intl.NumberFormat.formatRangeToParts() but it doesn't know it. I'll check if its there and use a fallback anyway. #JavaScript #ES2021

#javascript #jsdoc #typescript

Petite notation quand on veut typer un membre d'objet qui fait office de constructeur : ObjectConstructor<Object_Type>

Exemple :

interface TopBarApp {
enable: () => void;
disable: () => void;
}

type TopBarAppFactory = {
klass: ObjectConstructor<TopBarApp>,
}

#dev #web

I love that I can add CSS custom properties to a Custom Element Manifest via JSDoc. Let's see if I can add the idents/keys as specific properties to a JSX style attribute object. #css #jsdoc #cem #webcomponents

it's one of those grim ironies in life that #JSDoc, the standard library/format for writing #javascript / #typescript documentation, has some of the worst documentation i've ever had the misfortune of trying to read.

https://jsdoc.app/

JS-TS monster v2.0 👾 #javascript #typescript #jsdoc

$// example use let panel = $(document.querySelector('.panel')); // HTMLElement panel.style.display = 'none'; let link = $(document.querySelector('a.more'), HTMLLinkElement); // HTMLLinkElement link.href = 'about:blank'; let login = $id('login'); // HTMLElement login.remove(); let loginField = $id('login_field', HTMLInputElement); // HTMLInputElement loginField.value = ''; let p = $tag('p.details', { text: 'Info' }); // HTMLElement p.innerText = 'About'; let img = $tag('img.icon', { src: accountAPI.user.avatar }, HTMLImageElement); // HTMLImageElement img.loading = 'lazy';$

function $tag(tag, params, type) {
let element;
let parts = tag.split('.');

if (parts.length > 1) {
let tagName = parts[0];
element = document.createElement(tagName);
element.className = parts.slice(1).join(' ');
} else {
element = document.createElement(tag);
}

if (typeof params === 'string') {
element.className = element.className + ' ' + params;
} else if (params) {
for (let key in params) {
if (key == 'text') {
element.innerText = params[key];
} else if (key == 'html') {
element.innerHTML = params[key];
} else {
element[key] = params[key];
}
}
}

return /** @type {T} */ (element);
}

/**
* @template {HTMLElement} T
* @param {string} name
* @param {new (...args: any[]) => T} [type]
* @returns {T} */

function $id(name, type) {
return /** @type {T} */ (document.getElementById(name));
}

/**
* @template {HTMLElement} T
* @param {Node | EventTarget | null} element
* @param {new (...args: any[]) => T} [type]
* @returns {T} */

function $(element, type) {
return /** @type {T} */ (element);
}

function $tag(tag: string): HTMLElement;
function $tag<T extends HTMLElement>(tag: string, type: new (...args: any[]) => T): T;
function $tag(tag: string, params: string | object): HTMLElement;
function $tag<T extends HTMLElement>(tag: string, params: string | object, type: new (...args: any[]) => T): T;

JS-TS monster v2.0 👾

#javascript #typescript #jsdoc

🪲 VS Code #bug : if a string contains "//*" then VS Code thinks that the rest of the string is a #JSDoc comment.

How the string "//*" throws off VS Code's text highlighting system.

While working on porting the Small Technology Foundation web site¹ to Kitten², I took the opportunity to pull out base Model and Collection classes that I’ll likely end up including in Kitten proper:

• Model: https://codeberg.org/small-tech/site/src/branch/kitten/app_modules/database/Model.js
• Collection: https://codeberg.org/small-tech/site/src/branch/kitten/app_modules/database/Collection.js

To see them in use, here’s the base Posts class (with RSS generation) that extends Collection:
https://codeberg.org/small-tech/site/src/branch/kitten/app_modules/database/Posts.js

And here’s the concrete EventPosts collection class that extends Posts:
https://codeberg.org/small-tech/site/src/branch/kitten/app_modules/database/EventPosts.js

And the EventPost (showing an implementation of a calculated property):
https://codeberg.org/small-tech/site/src/branch/kitten/app_modules/database/EventPost.js

So all this is possible (persisting and reading back typed model collections, etc.) thanks to JSDB¹ (JavaScript database), a zero-dependency, transparent, in-memory, streaming write-on-update JavaScript database I wrote for the Small Web that persists to a JavaScript transaction log and is included as as first-class citizen in Kitten.

https://codeberg.org/small-tech/jsdb

And if you want to know how the magic mapping of classes happens, see the Database App Module:

https://codeberg.org/small-tech/site/src/branch/kitten/app_modules/database/database.js#L34

PS. For a much gentler introduction to persistence in Kitten, see the Kitten Persistence tutorial:
https://kitten.small-web.org/tutorials/persistence/

Enjoy! :kitten:💕

¹ https://small-tech.org
² https://kitten.small-web.org

#Kitten #SmallWeb #SmallTech #JavaScript #database #JSDB #typeSafety #JSDoc #closureCompiler #TypeScript #workInProgress

$Screenshot of code for index_[optional-postId].page.js open in Helix Editor. Highlighted section is part of a <select> control definition in a JavaScript template string that translates a list of event posts into option elements that begins ${db.site.events.list.map(post => kitten.html`<option value='${post The code is partially obscured by a language intelligence popover that’s showing type information for the list property: (property) Collection<EventPost>.list: EventPost[]. Generic list. @type - {Array} In the rest of the visible code, you can see post.title being accessed.$

Looking for advice on how to refactor legacy #JavaScript #frontend code (My expertise is on backend).

I know how to write relatively clean JS / #TypeScript for frontend in modern setups with modern tooling, but I'm not sure how to proceed with thousands-of-lines long files that are directly included as they are, so I can transition to having smaller & cleaner files and using static analysis tools that give me some peace of mind.

My only achievement so far with my current project is that I run #BiomeJS on some selected files.

I'm relying on #JSDoc for now, but "for my eyes only", I'm not using this typing information to validate anything.

#refactoring #legacycode

#JSDoc ist einfach das bessere #TypeScript 😄

Je cherche en ce moment un outil de génération de #documentation #javascript .

J'utilise #jsdoc <https://jsdoc.app/> depuis des années mais j'essaye de voir s'il n'existe pas autre chose de plus simple et léger (écrire un modèle pour jsdoc c'est vraiment un calvaire !)

Je jette un œil du côté des #plugins de #vscode et les résultats de recherche sont maintenant pollué par tout un tas de conneries basées sur #ai .

Ce métier est foutu !

How did I not know about this?

I just discovered that it is possible to enable #typechecking in #vscode for #javascript files (using #JSDoc comments).

This is a fantastic feature. It doesn't require any compilation step (like #typescript would) while highlighting potential problems in my code.

Found a great article by @stefan that explains how to set this up:

https://www.stefanjudis.com/today-i-learned/vs-code-supports-jsdoc-powered-type-checking/

Trying to bring some type-checking to webc components in @eleventy via #jsdoc comments

Screenshot of webc component code with `// @ts-check` type-checking

I looked for a #JavaScript framework that does not require a build step but still has good support for types with #JSDoc and has a functional API. The usual suspects, #Vue, #React and #lit do not fit this description.

I came across this tiny framework that does. https://github.com/grucloud/bau?tab=readme-ov-file#sample-code

#jsdoc

Client Info