How to Change Browser Path Without Page Transition in TeaVM Flavour (e.g. for Modals)?
Kerby
Normally the browser path changes on page transition like in:
```
@BindTemplate("templates/index.html")
public class IndexView {
public List<Coaster> getCoasters() {
return State.getAllCoasters();
}
public void handleClick(Coaster coaster) {
Routing.open(ClientRoute.class).coaster(coaster.getId());
}
}
```
However I have this requirement that the browser path needs to be updated with the same browser history push not on page transition but on modal display, e.g. in my app there is a modal that is "ViewSubmissionModal" which the path should change to "/submissions/:submissionId"
Similarly, is there a way to read the browser path, e.g. when page is served through SPA filters, e.g. "mydomain.com/submissions/:submissionId" then during page load to read the submissionId to also trigger the modal to show?
Alexey Andreev
I'd like to remind you once again, that Flavour is no more maintained,
so I would not expect that anyone answers you question. If you want to
write a web application, consider using Vue, React or Angular. If you
want to use some shared logic in a web application, you can produce a JS
module from TeaVM, as described here:
https://teavm.org/docs/runtime/js-modules.html
In case you want to try to push the idea of writing Web UI using TeaVM
and some framework like Flavour, I can understand that and I'd like to
encourage you to start maintaining Flavour. You can simply create a fork
and start patching/publishing new versions/documentation, you can create
a user group or Slack/Discord chat and start supporting people. But in
this case the only thing that can help you figuring out things is
learning the source code. Otherwise, I advice you to give up and stop
trying Flavour. Hope for your understanding.
Note that whoever claims they are "maintaining" Flavour and "using it in
production", I'd say they pretend to maintain the project, but in
reality doing nothing.
Kerby
Hi Alexey, thank you for your response. Yes, I’m referring to the SourceForge fork of TeaVM Flavour, which I understand you don’t endorse. I’m curious, why didn’t Andrew (the author of the fork) continue development within the original GitHub repository? Was there a divergence from your original vision for Flavour?
From what I can tell, the forked version still feels quite close to the original Flavour in terms of usage and experience. Are there specific technical or architectural decisions in the fork that you fundamentally disagree with? I’d really like to understand your reasons for not supporting the SourceForge version, especially since, for those of us building SPAs in Java, there aren’t many modern alternatives apart from GWT and Flavour.
As someone who's been developing with GWT for over a decade, I’ve found it excellent for UI-heavy apps like dashboards or admin panels. But when it comes to lightweight, responsive web apps, Flavour offers a noticeably faster and leaner development experience, particularly in terms of compile times and build speed.
Given all that, I wonder if this could be an opportunity to open a dialogue. Maybe the fork author could benefit from your perspective, and there might be a path toward alignment, if not on direction, at least on intent.
Alexey Andreev
> Hi Alexey, thank you for your response. Yes, I’m referring to the
> SourceForge fork of TeaVM Flavour, which I understand you don’t
> endorse. I’m curious, why didn’t Andrew (the author of the fork)
> continue development within the original GitHub repository? Was there
> a divergence from your original vision for Flavour?
>
for a slight chance that I revive it eventually. However, this does not
prevent to have a fork on github (or gitlab, gitea, whatever else).
> From what I can tell, the forked version still feels quite close to
> the original Flavour in terms of usage and experience.
>
> Are there specific technical or architectural decisions in the fork
> that you fundamentally disagree with?
>
> I’d really like to understand your reasons for not supporting the
> SourceForge version,
>
2. It's SVN
3. It's a couple commits per year
> especially since, for those of us building SPAs in Java, there aren’t
> many modern alternatives apart from GWT and Flavour.
>
for building SPAs, it's the area where it can't compete with React, Vue,
Angular and so on. Note that I don't mean technical part.
But if you *want* to change the world and have enough time, skill and
courage, you can try to start maintaining a fork.
> As someone who's been developing with GWT for over a decade, I’ve
> found it excellent for UI-heavy apps like dashboards or admin panels.
> But when it comes to lightweight, responsive web apps, Flavour offers
> a noticeably faster and leaner development experience, particularly in
> terms of compile times and build speed.
>
purely technical concerns. Software development tools don't always (I'd
say, often don't) appear and getting developed because of rational
reasoning. It's a bitter truth.
> Given all that, I wonder if this could be an opportunity to open a
> dialogue. Maybe the fork author could benefit from your perspective,
> and there might be a path toward alignment, if not on direction, at
> least on intent.
>
then I just forget to answer. One needs to be really pushy to reach me out.