okfn / opendataeditor

The Open Data Editor (ODE) is a no-code application to explore, validate and publish data in a simple way. Forever free and open source project powered by the Frictionless Framework.
http://opendataeditor.okfn.org
MIT License
163 stars 19 forks source link

391 document indexing and table store #397

Closed pdelboca closed 3 months ago

pdelboca commented 4 months ago

Fixes #391

This PR is part of understanding and documenting the indexing flow of tabular data.

@roll and @guergana I'm proposing this idea to start documenting what are the properties and when are they used. I think will improve a lot the readability of the codebase.

I couldn't find any reference nor use of the error?: types.IError property. @roll correct me if I'm wrong.

cloudflare-workers-and-pages[bot] commented 4 months ago

Deploying opendataeditor with  Cloudflare Pages  Cloudflare Pages

Latest commit: 47f3653
Status: ✅  Deploy successful!
Preview URL: https://7a2abb1e.opendataeditor.pages.dev
Branch Preview URL: https://391-document-indexing-and-ta.opendataeditor.pages.dev

View logs

guergana commented 4 months ago

Hello, @pdelboca I think it's a really good idea to document everything but I would suggest we write the comments as JSDoc annotations (Typescript seems to come with JSDoc support): https://www.typescriptlang.org/docs/handbook/jsdoc-supported-types.html or use another library for code annotations in Typescript.

The advantages of commenting in a standarized way is that it will be easier for developers familiar with JSDoc, there are clear docs of what JSDoc annotations mean and the annotations could be later included in a script to automatically generate docs. The con is that we need to learn the JSDoc syntax if we wish to go beyond writing basic comments. But I think the advantages outweigh the disadvantages.

I mention JSDoc because it is the one I am most familiar with, but there seem to be others like Typedoc, and TSDoc and probably others. In case we decide to take this route we need to make an investigation and decide which library would better suit our needs for the project. :)

If you think it's too much I am also happy to go with the simple comments, but we would still benefit from writing the comments in JSDoc format in case we change our minds in the future (meaning we can start off with JSDoc comments in the simplest format and then expand to add more complex JSDoc annotations)

/* This is a normal comment */
/** This is a JSDoc comment */

You can see some simple examples here

pdelboca commented 4 months ago

@guergana I agree with a better syntax, I migrated to the simple comment structure /** comment **/.

The idea is to have a way to start adding comments as we understand the code base. We will have a proper time to document at the end of the project so let's start with the simplest way possible :)

roll commented 4 months ago

@pdelboca If TypeScript lets you something to remove -- than it's not used =)