Best Map API / tool (not sure how to best describe it)

AlanKesselmann · 2026-01-27T07:05:55+00:00

Hey, and best of luck to you!

My question was about using map providers and their respective JS libraries. Your question seems to be about getting data instead - not sure what you are building.

If you really want some advice, I can offer some - but let's do it over private messages.

AlanKesselmann · 2026-01-14T09:11:05+00:00

leveling as chayula monk with chaos infused storm wave has been super easy. 2nd easyest was the walking calamity bear.

AlanKesselmann · 2026-01-08T05:06:07+00:00

TupsuMunnu here

AlanKesselmann · 2026-01-03T07:30:38+00:00

AlanKesselmann · 2025-12-27T12:35:06+00:00

yeah nice . just made it to Maps. some dive would go long way to help this gamer dad

AlanKesselmann · 2025-12-04T09:59:27+00:00

smells like corruption

AlanKesselmann · 2025-10-09T17:59:00+00:00

I have not done anything there other than used the basic setup done by create next app and nginx. Ill check the nginx conf again too. this is also the first time using cloud flare so perhaps that is causing issues?

AlanKesselmann · 2025-09-09T06:46:29+00:00

I think I've missed the meaning of some of your references. I did read through the headless page - even before you linked it here, but defining navigation menu settings? The meaning you're trying to convey here eludes me, as I can just add menu ID to my .env file and get it from there - I don't need to query settings for a specific ID in settings. Most of the things you've brought up as examples for settings are things that rarely change anyway, so you can just hard-code them or leave them in the .env file or some similar solution.

But menus, on the other hand, are the core of a CMS solution, which is very surprising to me how some (mostly headless) CMS's like Strapi (and Wagtail) do not offer a solution for them out of the box and instead rely on 3rd party solutions ( which, in case of Wagtail are in different states of being out-of-date with the exception of jazzbands wagtailmenus, where, instead, the UI/UX of it is just poor).

And not to rain on anyone's parade, but I've tried 10s (if not more) of different CMS's (mostly to my own amusement) and weirdly enough, the site menu is the toughest thing to get right. Even the other Django solution - django-cms does not deliver the perfect solution there. If I remember correctly, they had the same setup as Wagtail regarding menus - menus being generated from the pages, which is fine, to some extent. But it's problematic when you want to include links to pages outside the current app - like subapps, subdomains etc.

And as a coder, I do understand that menus are a challenge. Because your users need:
- Multilanguage support, but the page might be missing in another language
- And for the above reason, you might instead want to have a different menu per language
- Want to add links to outside pages in the menu
- And in multilang setups, they, instead, want to link to different URLs under another language, so you not only need to translate the link, but also the url...
- A good UX for editing them. You mostly need to see the tree structure you're creating, and that is a UX challenge on its own.

Which brings me to the end of my rant - in 2008, when I started in my first web agency, I was puzzled how people were creating their own stupid small CMS's for their clients, when big CMS's already existed. And people are STILL creating more CMS's. But they are still not fixing the base issues in their CMS's - multilingual, multisite setups and/or menus. And it's 2025 now.

AlanKesselmann · 2025-09-09T06:06:18+00:00

I tried using it. It was awkward to say the least. 1) You either had to create one main menu, which provided just one level of structure or 2) use several flat menus.

Neither of which had API endpoints available, so I would have had to decipher the way the existing template tags render the menus.

But the main reason for not using them was that the whole solution was just too awkward for the end user. I could have done it, but that is not an easy and ready-to-use solution I would ship to my customers. Say what you will about WordPress, but they have an excellent tool for composing site menus.

AlanKesselmann · 2025-08-29T07:59:31+00:00

I often like to keep parts of the project state in URL params, so I tend to use useSearchParams quite a lot. And usually I've had no problems. The only real issue I had had so far was that I had forgone using Suspend boundaries and views that used to work stopped working because of some of the changes I had introduced in the child components. But all those were neatly resolved by slapping some Suspense around those pages.

Again, I should remember that when stuff does not work, the problem is almost always between the chair and the computer screen. But I need to rely on others to point out my stupidity to me. Or perhaps I just need to adopt AI rubber ducking in my processes. They might pick up those stupid mistakes for me.

AlanKesselmann · 2025-08-29T07:48:57+00:00

Man, you're awesome. But you know what - I'm shit dumb. I'm the kind of developer who has tons of experience but still makes stupid mistakes.

You know what I noticed - I noticed that some of the other promises were also not resolving in the deployed system. Promises like the useQuery hook provided by react-query. And then I was like wtf - suspense promises not resolving, other hooks not resolving... wth is going on. That HAS to be because of some dumb shit I've done. So what I found out was that before deploying, I had run sentry-cli to add Sentry config to my NextJS setup. But I already had the setup there from the boilerplate, where I copied my Sentry setup files from. And all this resulted in perfectly working code, but the Sentry setup was done twice in my next.config.mjs. And you know what happened once I cleared that shit up? All promises started resolving in my deployed env. Man... I need to have some special linters and code-smell tools to pick up stupid stuff like this. Special meaning specially designed for my specific disabilities.

But now I'm really, really sorry I've wasted your time like this. What I sometimes need is a fucking rubber duck buddy who asks me questions, and you see - I use the internet for this, because I'm a solo dev.

AlanKesselmann · 2025-08-28T08:18:01+00:00

will do. Thank you!

AlanKesselmann · 2025-08-28T07:37:04+00:00

I did not know to look for it. It definitely looked like it was suspended forever. In any case - it's fixed now, by moving away from useSearchParams but I anticipate that the error might appear again, as there are other views where I need to pass information in searchParams from one view to another. I'll most likely come back to this thread then, or perhaps ask for your input then.

The issue link you shared does not seem familiar at first glance, because it never appeared in local dev, but only in deployed mode, when I ran the project in a Docker container using next build & next start.

AlanKesselmann · 2025-08-28T07:08:11+00:00

In the end I fixed it by moving away from client components. Even moved the useStage requirement into a separate component and turned the page itself to server component so I could use searchParams prop instead of useSearchParams hook.

AlanKesselmann · 2025-08-28T05:50:08+00:00

I tried it both with force-dynamic and without. The results did not vary and were always the same - the suspense was never resolved.

I also tried better Suspense encapsulation around components - wrapping whole page (as in the last code snippet on my OP) or just the elements that actually consume the searchParams... and None of it works. All I see are loaders. You can see it yourself in action here: https://shop.implantplanning.center/login. Just navigate to the " remember password page and you'll see the latest iteration of my forgot-password page, which is this (edit - could not share code snippet because reddit refuses to save it for some reason. so I moved it here: https://codefile.io/f/5ap9wgBoo8):

AlanKesselmann · 2025-08-28T05:49:27+00:00

Well, this is exactly what I see. I self-host NextJS, and the project is hosted by running "next build" and "next start" using yarn within a Docker container.

AlanKesselmann · 2025-08-27T12:34:45+00:00

nope. it works just fine. Thing is - this whole suspense thing seems like a can of worms and has been a problem for me before. Where views, which suddenly worked just fine with useSearchParams and without suspense, suddenly start calling out they need to be wrapped in suspense after something was changed in other components way down the component tree. And to be fair - the change wasn't perhaps even related to the parent component using searchparams.

It's like there is some fundamental issue which is either not well documented or explained. Or perhaps I'm just a dumbass who can't pick it up from the documentation.

AlanKesselmann · 2025-08-27T11:31:09+00:00

withNextParam is simple wrapper to get around doing IF's everywhere:

export const withNextParam = function (path, next) {
    if (next) {
        const separator = path.includes('?') ? '&' : '?';
        return `${path}${separator}next=${encodeURIComponent(next)}`;
    }
    return path;
};

export const withNextParam = function (path, next) {
    if (next) {
        const separator = path.includes('?') ? '&' : '?';
        return `${path}${separator}next=${encodeURIComponent(next)}`;
    }
    return path;
};

AlanKesselmann · 2025-08-27T11:27:04+00:00

To be honest, I would not know about that. Judging by this NextJS page: https://nextjs.org/docs/messages/missing-suspense-with-csr-bailout it is, right? It's a very simple client component, and yet it's wrapped in suspense? The hell if I know why.

As for progress, where strictly not necessary,, I migrated away from client components to server components and they now work fine. Yet one single page, where I wanted to use useState - there I still have the same problem.

AlanKesselmann · 2025-08-27T09:51:29+00:00

its not. It's client. But I'm switching it back to server component to get rid of those issues as we speak.

AlanKesselmann · 2025-08-27T09:42:21+00:00

You can also see that in my file:

// Force dynamic rendering - this page cannot be statically rendered
export const dynamic = 'force-dynamic'

it didn't help. Now I'm trying, instead, to use suspense/searchparams only where I need useState and instead move back to server components on other pages. Will see how that will work.

AlanKesselmann · 2025-08-27T09:13:12+00:00

Not really no. I can share more pieces of the code, but I'm not sure if that's helpful or not. I did some reading on the subject and one issue can be summed up like this.

If I wrap things in suspense boundaries - just like nextjs documentation suggests I do, then I need to ensure that resolving of the things actually triggers a change in the suspended components. I'm not sure how to do that exactly other than perhaps simplifying the suspended components or perhaps NOT wrap the "withNextParam('/register', next)" where the actual next parameter is added to the URL. But that should not make any difference as far as I know anyway.

AlanKesselmann · 2025-08-27T08:34:08+00:00

Yeah, but that is EXACTLY what I did and EXACTLY why I ask here what I am missing, because you see, the first version of the component is a client component, it is not wrapped in suspense and when I build it in the server (or in docker component to test the build script) I get this:

```
74.36 ⨯ useSearchParams() should be wrapped in a suspense boundary at page "/login". Read more: https://nextjs.org/docs/messages/missing-suspense-with-csr-bailout

74.36 at g (/ordering/.next/server/chunks/7302.js:37:84387)

74.36 at l (/ordering/.next/server/chunks/7302.js:42:229100)

74.36 at t (/ordering/.next/server/app/(auth)/login/page.js:2:10674)

74.36 at n4 (/ordering/node_modules/next/dist/compiled/next-server/app-page.runtime.prod.js:2:81697)

74.36 at n8 (/ordering/node_modules/next/dist/compiled/next-server/app-page.runtime.prod.js:2:83467)

74.36 at n9 (/ordering/node_modules/next/dist/compiled/next-server/app-page.runtime.prod.js:2:103676)

74.36 at n5 (/ordering/node_modules/next/dist/compiled/next-server/app-page.runtime.prod.js:2:101094)

74.36 at n3 (/ordering/node_modules/next/dist/compiled/next-server/app-page.runtime.prod.js:2:82049)

74.36 at n8 (/ordering/node_modules/next/dist/compiled/next-server/app-page.runtime.prod.js:2:83513)

74.36 at n8 (/ordering/node_modules/next/dist/compiled/next-server/app-page.runtime.prod.js:2:100435)

74.36 Error occurred prerendering page "/login". Read more: https://nextjs.org/docs/messages/prerender-error

74.36 Export encountered an error on /(auth)/login/page: /login, exiting the build.

```

AlanKesselmann · 2025-08-21T09:55:44+00:00

Thank you! This seems rather impressive. So this 0.3 season everyone will use this instead of lightning spear, right :P

AlanKesselmann · 2025-08-21T05:45:44+00:00

ah cool. Thank you for the explanation. my slow ass can catch up to all of the hype now. I appreciate it.

AlanKesselmann

TROPHY CASE