Folder name as parameter about routify

[Wolfr]

What I am trying to do:

• I have a list view A and a list view B
• I have a detail view whose data depends on whether you came from A or B, and shows content based on an id in the list view

I am trying to find the most elegant way to implement this.

[Wolfr]

Here's some code I was trying:

import { url } from '@sveltech/routify';

then

<a href={$url('/:language/:detail', { detail: character.romaji, language: 'hiragana'})}>
    {character.character}
</a>

[jakobrosenberg]

What you're showing in the screenshot should be fully supported.

Any chance you can give a specific example of your scenario in the second post?

[Wolfr]

I created a branch for my specific situation.

https://github.com/Wolfr/kana-master-svelte/tree/replay

Here you can see {language} is undefined, I would expect it to be "hiragana". I did export let language from the detail.

[rixo]

Test says there's no problem with param in folder, in basic cases.

[jakobrosenberg]

I think this probably comes down to the "drafty" documentation.

The way it's intended is that if a page has a [parameter], the parameter is passed to the page as a prop. In the case of a folder, the parameter is passed to the _layout.svelte (which for all intends and purposes could be considered _folder.svelte).

To access all parameters, you can use the $params helper.

[rixo]

@Wolfr You repo is giving an error about a missing component, but once that commented out, I can confirm the problem.

For the record, I hadn't pulled the last master. The test is indeed falling with last Routify version, and was passing with the previous version. So what you're trying to do was possible but isn't anymore.

Accessing parent params from page components' props might not be supported in the future. For now, the recommended approach is to use the $params helper, like @jakobrosenberg said.

[Wolfr]

I found a way to solve my problem but it is kind of wieldy.

$: Object.keys($params).forEach(function eachKey(key) { if (key == "language") { language = $params[key]; }});

This to make sure that the language param works.

[Wolfr]

My evening-of-coding result https://kana-master-svelte.now.sh :)
Source code: https://github.com/Wolfr/kana-master-svelte

Any ideas for optimizations regarding routing welcome.

[rixo]

What about?

$: ({ language } = $params)

I don't think it is a good idea to only set the variable if the key is effectively present in $params. You'd better stay in sync with what's in there. If the value is required and not present, you have a problem that you need to fix anyway, elsewhere.

Continuing to use a stale value doesn't seem like the proper solution to me. If your code really can't live without a value for language, I think throwing an exception would be better.

[Wolfr]

Thank you, that is smart and looks cleaner. Not sure if I fully understand it though 😝

Now, currently, if I use the back button in my app now, regardless of using your solution or mine, it throws an error.

I have the feeling that I don't know enough about how reactive stores should interact with the parameters, I am a bit out of my depth here. At this point it could be a bug in my logic or a bug in the framework.

I am linking to two levels back, is this supported behavior or not?

<Button variant="ghost" icon="chevron-left" href="{$url('../../')}">Back</Button>

Sorry if this feels too much like QA for my app, but since Routify is relatively new I thought I would ask.

[jakobrosenberg]

That is supported. I was writing my router suggestions here, but eventually figured it would be easier to just show my idea. I'll push a makeover very soon.

[jakobrosenberg]

There was a bug in Routify, which updated the internal store before the page/layout had been destroyed, meaning that your component could be left hanging without the needed data. Pushing a fix now.

[jakobrosenberg]

I got very confused by the navigation on your site. The top level navigation seemed to be at the bottom below-the-fold; Katakana seems to be a subset of Hiragana, judging by the browser address and the navigational highlighting of links didn't work for Hiragana Disgraph, since Hiragana Monograph was on /index and Hiragana Disgraph was on hiragana-digraphs.

I can be a bit of a robot at times and others may find the UX intuitive.

I've rewritten a bit of your code to show off an alternative here.
https://public-fkf8u37xb.now.sh/

https://github.com/jakobrosenberg/kana

[rixo]

Just to clarify...

This:

$: ({ language } = $params)

is equivalent to this:

$: language = $params.language

ES destructuring + Svelte reactive declaration... Said otherwise, lots of sugar!

[Wolfr]

Hi Jakob, for your informatiom. This is a rewrite (WIP obviously :)) of an iOS app. This is supposed to be a mobile app with a tab bar in the end, you can see what is supposed to look like at http://kanamaster.com/ .

The relationship between the two that Katakana and Hiragana are two scrips, and both have digraphs.

I'll check your code to see what I can learn!

[jakobrosenberg]

That explains it. :P

The gist of what I did with your code was that I moved all the individual pages into /:graph/:language and unified them in one page and treated each graph/language as a prop to be fed to the maingrid.

You can shift this around to your liking.