Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

refactor: change storage.slides.id to a more meaningful name #252

Open
GuiLeme opened this issue Sep 12, 2023 · 0 comments
Open

refactor: change storage.slides.id to a more meaningful name #252

GuiLeme opened this issue Sep 12, 2023 · 0 comments

Comments

@GuiLeme
Copy link
Contributor

GuiLeme commented Sep 12, 2023

Is your feature request related to a problem? Please describe.
The problem here is really the confusing names we gave the storage.slides.id, here is the deal:

We currently have 2 names which were supposed to describe the same thing, the page number of the presentation: id, currentPageId:

  • The currentPageId only appears in the context of tldrawAPI, which is the internal API of TLDraw, so we don't really need to worry about it, to my understanding. Moreover, its value is constantly equals to "page" (as far as I could get) which doesn't bring a lot of information for us. One more interesting thing is that we pass it over to parentId (see code previously linked in this paragraph);
  • The id can be interpreted as the page number of the presentation if it is inside the storage.slides.id as we can see from this snippet
    const slideId = getId(img._id);
    All it does is take the previous id directive from the shapes.svg xml (which would be slide1, for instance) and transform it into 1;

Almost the same happens to the tldraw.json file, which simply is a place to store the annotations, and there we have the number of the page as the key, which is parsed to an id key later on (see code here) and the data which contains all information on the shape drawn (for example id again which in this case would mean id of the annotation).

Describe the solution you'd like
My thoughts on this is that it should be less confusing, as though we wouldn't feel obliged to look into how those things are built in order to get an insight of their meaning.

So we should rename those ids that mean exactly the same thing (the page number) to a more meaningful name, like pageNumber or slideNumber.

For now, I guess a changing in the building process of those data, should be enough (meaning change only bbb-playback). But later we should discuss if the names are meaningful for the record-and-playback in the archiving phase as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant