messman / tidy Goto Github PK

Alas, you used to know the difference. Update the code to use the proper term, whatever it is.

And here I was, actually optimistic for a bit that it would Just Work.

Why's it so bad?
We use local dependencies between the projects in development (file references in package.json) and we don't host any of the code publicly on npm. This puts us in a unique situation when trying to bundle code.

Current process

• Run a special tsc in server-http to build for the azure-deploy directory
• For shared and server, build them with production settings and npm pack them
• Install regular dependencies with the ad-hoc package.json

Not too bad, but could be better.

Users (like my sister) of older versions enjoyed the crab that sat on the rock. Try to bring back some version of that or other marine life.

Maybe not always visible, but shows on changelogs or special alerts?

From dad's iPhone 8.

Could be that the top and bottom bars added by Safari shrink the height to below 500 and I have code to throw up that message.

From dad.

Wants:

• Link to the station page
• Number of the station and rough location in Wells
• A picture of the station from the site

This could be a new panel on the settings page.

When the application refreshes data, some pieces (like the tide chart or sun chart) flash to update (because they require knowledge of their bounds). We should animate these for a smoother effect.

Additionally, the loading screen should transition in and out using opacity. A generic component could be added to handle this.

Looks like there are about 10 right now.

Thought of this while working on the settings page - why not include some of the information learned about tides while creating this app?

Some of the things to talk about:

• Why tides are 6 hours apart, not 12
• If tides are always the same time apart, because it doesn't seem like it
• To what extent the sun influences the tides
• How tide heights are displayed in this application (relative to what?)

This application really only works when the data is fresh. If the user has the application open for awhile (maybe 5 minutes), we should prompt them to refresh.

And let readers know they exist in each project folder.

Right now the logic for determining timeline time is "end of this day, plus 2 days". That means we could end up with almost 72 hours of timeline, which is at least 3600 pixels.

Use hours instead, so we can keep things manageable. Either update the API or do it all client-side.

Gotta help out those Canadians.

Raised by mom. Right now, day of week can be reasoned from timeline and forecast view but isn't apparent on the screen.
It's not 100% necessary feature-wise, but it's valid.

Moving from the dark theme to the light theme turns users off from the light theme - it's just too bright. Improve the contrast and maybe CSS transition between themes.

This is the big one - when moving between compact and extended size, we re-render a lot. That's not a common user case, but fixing it would be nice.

I figured this would be automatically configured, but it's not. Gotta figure out what obscure Azure setting this is.

In this application, the weather API data is different from tide or sun data - it is only recent. AFAIK, with this NWS API there's no way to go back in time to view yesterday's weather or the weather from earlier today.

That means that at 8PM today, the only weather information I have for today is 8PM to the end of the day - so I can't really create a good summary of that entire day for the Forecast view. Hence, why we only show 'Tomorrow' and forward.

There's probably either a different API from NWS or another API entirely that can provide this - it will just take some time to research.

Start goes with Stop, Begin goes with End,
But Start does not go with End, my friend.

Unfortunately, I forgot that until halfway through. I can feel the disappointment from my old coworker Kousay.

It could just be that this particular iPad is messing up, but take a look just in case. There is a CSS rule out there for controlling scroll style. Weird, though, the iPhone 8 Plus scrolled as expected.

Right now the timeline weather data is squished together so

• We can't explain the data we show (it's hard to know exactly what that status icon means)
• We can't show all the information we have (visibility, dewpoint)

We need a clean design to allow everything to be shown (probably on click/tap).

So that even if it goes down, people still see what it looked like

Three parts here:

• When the user first comes to the app after a new version, a pop-up will tell them what's new (only if it's important)
• They can see that info for the last few new versions in the app somewhere
• There is a link to a page on this GitHub repo with the entire changelog history

A quick test on timing reveals:

weather 1 done 6386.6288100034
predictions done 6415.023443996906
weather 2 done 6642.094659000635

Fix the madness with:

• Extra renders due to rogue useEffects
• Extra renders due to misuse of resizing code
• Abuse of styled-components

There needs to be a way, no matter what (barring a failure by React) for a user to see the basic information about the app:

• App name and purpose
• Developer and contact link
• Link to this GitHub repository
• Build version and time (to help with issue reporting)

In order to see this when there's an app-wide error, we might need to add a new icon to the menu bar and disable all other icons. Bleh.

The API is deployed on Azure, so it's subject to go to sleep after 60 (?) minutes of inactivity. Then it needs to warm up, and so the first request by a user may fail.

Conveniently, the user can tap the screen to try again. But maybe increase the timeout a little more to lessen the chance of that happening.

There used to be one, but it was likely deleted.

https://ogp.me/

This is the obvious "next step" for this application and would help its adoption with a wider audience.

What stands in the way, as I see it now:

• I'm not sure what the request limits are on the APIs I use for tide data and weather data, so I'm trying to be more on the cautious side. If we hit the limit because of more users we could get banned.
• It's more difficult to cache more locations. I'll need some storage.
• This feature would mean potentially more users, which could mean abuse of the public API, so I'll have to focus more on security and maybe add auth.

In order to:

• Have a record so you can remember what a pain in the ass this project was
• Remember and document some of the interesting problems you encountered
• Impress people who think this was an easy project
• Help others going through the same issues

Part of the original design of this page, but was moved out of MVP.

Some elements on the page, like the summary blocks, can be tapped to show more information. There should be some UI indicator to let a user know that they should try to click or tap.

This indication could be turned off or could automatically turn off once the user has tapped correctly once.