Game is a complex thing and it would handle it perfectly. Believe me it handles really well also simple cases. For me it's not a first iteration on the idea of routing automation. It gives you freedom and is really handy. Even if you never thought defining routes is a problem. I hope you'll give it a try.
Why are you showing something that's rushed? If this is a personal project what's the deadline? Why not wait until you have a finished product (eg hosted on a proper port 80 web URL with a domain name)
Thank you for your advices. What can I say - I am and I will be in a rush for a while. I have also bigger personal projects. I'm glad I was able to ship it now. I have good feedback and I'll make it better thanks to your comments. I'm glad you took a while to see it despite all defects of the project site. If you like it please subscribe or connect me on twitter - I doubt I'll reach your attention again. Promoting personal projects is incredibly hard.
Nice one :) You decide what you keep in url. Use case of google map when you're scrolling a map and you want to share a location with your friend is not vulnerable, right? Now it's easier
1. Please explain me what you'd like to know. Router is one layer of SPA / PWA so you need it if you want to make one. It's framework independent and I'd not like too add more dependencies to your project for such a small thing - even if it's powerful.
2. If you want to check it out quickly with minimal effort, play in your browser js console - it's there.
Can someone please ELI5 what I'm supposed to be seeing? I just opened this page and saw a bunch of buzzwords. What is this? What is this for? Why is it hosted on an IP address?
I just disagree with declaring paths with kind of regex pattern matching set of rules. This approach is flexible and natural. It will not stop you when your application became complex and even with simple cases it's faster - you touch less places in your code to make a change.
You can use anything with this router (redux too). I agree react router is a nice tool - but in a classic paradigm. The difference is - you don't define routes. If you create a component and it needs a data you just ask the url store for it. Or if you need to persist some data you just write to the store. It creates nice urls - always a name and a value. Additionally you have setters which will handle a serialization of your object to nice string. And of course getters which will wrap your data into a custom object - so it's not a string.
I think I see what this is for, despite the unilluminating site. Storing state in the URL is a good idea - it lets your users bookmark and share links to your application's state.
I have a couple of questions though:
When I have done this in the past, I have used the url fragment to store the state, i.e.: https://sheep.horse/tagcloud.html#computing . This works even with static sites because the browser doesn't send the fragment (everything past the # symbol) to the server.
By encoding state in the path of the URL, you require server support. I guess the flip side of that is that your site can continue to work without js support.
I notice that your demo and docs don't mention anything about manipulating the browser's history to allow the user to move to previous states using the back button. That can be a pretty useful thing to provide.
Fragments are worse than described here. Fragments are incompatible with redirects. Not only does the browser not send them, but any server-side redirects will either require active-JS redirects to capture and redirect the fragment, or strip the fragment as inappropriate/pointless, or if you're very lucky, maintain it somehow through the redirect. Do not use fragments for any critical function without vetting your entire workflow and all servers and useragents in your request/response path.
What you say is absolutely true, and I agree. But I also subscribe to the URLs-are-user-interface school of thought and think that implementing redirects to change your UI requires careful thought. I'll admit that sometimes it is unavoidable as applications change over time.
Maintaining state in the path, query parameters, or fragment are all techniques that can work, but each comes with disadvantages.
I wonder if anyone has been mad enough to maintain state in subdomains:
You have a valid point about # and that it works on static site. I'm aware of that and I'll add this as a feature so you'll be able to choose on init().
Please explain me the part about back button on example.
Regarding the back button: take your demo page (youurlh/switcher/) as a perfect example, you can click on the "lights off" link and be taken to yoururl/switcher/night/1. I would expect the back button to take you back to the original switcher url and turn the lights back on, but it doesn't.
This is because your write() function uses relaceState() to modify the current url. If you used pushState (like your go() function does) then the browser would correctly maintain history.
Now, maintaining a history of the current state is not always the best thing to do. For instance, on your other demo page, the one where you type your name, you probably don't want to push a history item for each key press.
I think you should consider offering the option to push local history so that an app developer can decide if it makes sense.
Oh yes. I was considering that. I've stayed for a while with a convention solution - write and toggle replaces, but go adds to the history. You can build on top of that, but I think it's reasonable now.
It manages for you what you want to be in a history. Imagine example with an input which writes on each keyup to the history and going back letter by letter.
So when you click on a "link" it goes to the history. If you play with params on a single view it replaces.
I think I like the idea, but the docs are a major puzzle. This is a library for mapping URLs to data (or function calls? not sure) without a single URL in the docs. There is also a demo, which shows that it works, but not how it works (no source code displayed except if i want to dig down in the entire site's source code).
All I see initially is a white screen. Then realized I had to scroll down (and oddly to the right!) in order to see any content. Clicking on "DEMO" leads to the same thing (scroll right for actual content) but with super large text and oddly-placed elements. Still not quite sure what this is about, but it looks like a neat art project?
51 comments
[ 2.7 ms ] story [ 105 ms ] threadI tried scrolling to the left thinking there was more content, but that was it. It looked better on Chrome when I set the size to be 80%.
If this is 67 lines of code with zero dependencies, why do I need it as a dependency?
Regarding CDN implementation, why would anyone add an HTTP request to the page for 900 bytes?
2. If you want to check it out quickly with minimal effort, play in your browser js console - it's there.
sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 3000
It's nice but I'm still not sure when to use it and why you made it.
Maybe you could add your personal use and motivation to it? Otherwise it's a clever library.
Why the word "routerless" is in the title is a mystery to me.
I have a couple of questions though:
When I have done this in the past, I have used the url fragment to store the state, i.e.: https://sheep.horse/tagcloud.html#computing . This works even with static sites because the browser doesn't send the fragment (everything past the # symbol) to the server.
By encoding state in the path of the URL, you require server support. I guess the flip side of that is that your site can continue to work without js support.
I notice that your demo and docs don't mention anything about manipulating the browser's history to allow the user to move to previous states using the back button. That can be a pretty useful thing to provide.
Maintaining state in the path, query parameters, or fragment are all techniques that can work, but each comes with disadvantages.
I wonder if anyone has been mad enough to maintain state in subdomains:
https://accnumber18573.color-yellow.example.com/
Please explain me the part about back button on example.
This is because your write() function uses relaceState() to modify the current url. If you used pushState (like your go() function does) then the browser would correctly maintain history.
Now, maintaining a history of the current state is not always the best thing to do. For instance, on your other demo page, the one where you type your name, you probably don't want to push a history item for each key press.
I think you should consider offering the option to push local history so that an app developer can decide if it makes sense.
It manages for you what you want to be in a history. Imagine example with an input which writes on each keyup to the history and going back letter by letter.
So when you click on a "link" it goes to the history. If you play with params on a single view it replaces.
What do you think?
@madmaniak, add some examples, please :-)
Step 1: Attach pro-router
Step 2: R.init(root: 'helloworld')
Step 3:
R.write('foo', 'bar')
# url changes from '/' to '/helloworld/foo/bar'
R.param('foo') # => 'bar'
Please ask me any use case you'd like to solve. I'll try to explain more.
If you can ignore the layout you'll find neat art project for frontend routing :)