Missing seconds

[mo-esmp]

Not a big deal, however, may cause some logs to be missed. @followynne better to handle in UI or in Code?

[followynne]

Uhm, that's a good point! I think we could make the search input more precise in the UI - we can think of doing this fix in the new repo 😊

Actually, I was thinking about transforming the JS app into a React-based one, for fun... Do you think it would be something interesting/useful/you'd like? We could revamp the UI by replacing Bootstrap with another design system style 😂🥸

[mo-esmp]

I do like to change the whole UI and there is an issue related to it. The next move for this project would be adding analytics and for sure we need better UI.

[followynne]

Okay, we can try to improve it - if we're okay with moving to React, I can take charge of the current UI migration/refactor and start doing it as soon as we're on the new repo 💯

I would only need a couple of things:

• which design sys should we use it? Keep Bootstrap or do we switch to another (here some https://retool.com/blog/react-component-libraries/)? I'll leave this one to your personal choice 😄
• should we investigate the chance of migrating the current UI index.html injection to a Razor view registration (like they do in Hangfire)? I did something similar in another project, thus we could try it :)...
  [on another topic, if we switch to Razor controllers etc, we should be able to try out React Router to intercept and do multi-page SPA on the same URL; I did it some time ago, we could give it a try...]

If you confirm me about React, I'd proceed with this todo:

1. (prerequisite) repo migration
2. update & re-open the SortBy option PR
3. migrate UI to React

Let me know 😉

[mo-esmp]

• I'm ok with moving to another design system and using react and you could make a choose
• For version 1, I developed UI with Razor then I decided to follow Swachbuckle middleware approach because the UI was a single index.html with CSS and Js files. To make a long story short, can move back to Razor if it's required
• After repo migration, we can start the design and planning phase

[followynne]

Awesome, thanks!
About the Razor part, we can test later the simplest approach.

On the design systems, I'll take a look around and propose some options, based on the React components they provide out of the box 🤗

[mo-esmp]

What is your idea about Blazor? should we consider it as an option?

[followynne]

That's a good point - Blazor vs React is a topic I considered too many times 🤣

IMHO, those could be the key points to choose between them:

• React development should be quick to setup, since we only need to inlcude it with Parcel, while Blazor needs to be checked (nothing too difficult, I think)
• Blazor requires more work to migrate, because we need to re-implement the UI from almost zero, while in React we'll do a JS porting (in theory, it should be easier but I speak 'cause I'm more used to React than Razor :D)
• Blazor is better than React for C# devs, at the end, which makes it easier to dev for the library itself...
• React is well-known and used for web-app (which is not bad if you were to include it in a resume...)
• React has got way more libraries, that could come in handy to develop new complex components - on Blazor we're probably more restricted on the available choices
• Blazor should be better integrated in C#/MVC itself (I suppose)
• About Blazor, I don't see it widely used (I expected it to become more used after 2018~) - I'm scared it could go on the deprecated route too soon 😄

At the end, if I were to choose, I'd go with React because

• I already used it 🚀
• the JS migration should be easier and faster to setup...
• I like having lots of available libraries for the front-end, simply 'cause I hate doing CSS... 🆘

but it's really a matter of preferences, at the end :D

[mo-esmp]

Fair enough, let's go with React!

[mo-esmp]

I was trying to reproduce issue issue 96 and figure out that the time is shown wrongly. My time zone is GMT+1, and that's why there is a one-hour difference. Hence, we don't know how the actual sink saves time in UTC or local time; let's not convert to local time.

I checked the code and found out the formatDate function in the util.ts file changes dates. Is it related to time format PP H:mm:ss.SSS?

export const formatDate = (date: string) =>
  format(parseJSON(date), 'PP H:mm:ss.SSS', { weekStartsOn: 1 });

[followynne]

@mo-esmp

I think you're right, I need to check back the original formatting function - if I recall correctly, I did port it as it was originally. There could also be some relation with packages upgrade, I'll try to understand what changed between the 2 providers versions...

EDIT: probably it's the PP of date-fns, I'll check if I can improve the parsing format 😅