Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Request matchPath('*') #27

Closed
nairihar opened this issue May 24, 2018 · 8 comments

Comments

Projects
3 participants
@nairihar
Copy link
Contributor

commented May 24, 2018

I think it will be good if user can receive request using '*' symbol.
As I noticed you use "path-to-regexp" library, If it's good feature and you want to have this I can help you, just I need to know should I use "path-to-regexp" or something other?

Thanks

@JozefFlakus

This comment has been minimized.

Copy link
Member

commented May 24, 2018

Can you post here some code samples for use cases?
Right now if Effect doesn't compose matchPath operator it behaves like matchPath('*') - it handles all requests in his group. In my opinion adding custom matcher like this can be redundant and will obfuscate the matchPath logic. But if there are some other use cases that we are not aware of we can think about this idea.

@nairihar

This comment has been minimized.

Copy link
Contributor Author

commented May 24, 2018

In Marble If we want to handle routes which has 404 status (not found that path) how we can do that ?
As I understood from source code we can't.

Also we can add some "not handled error" Observable where user can subscribe and do some work for that error.

@nairihar

This comment has been minimized.

Copy link
Contributor Author

commented May 24, 2018

Also I think will be cool to handle routes with matchPath using regex.

@couzic

This comment has been minimized.

Copy link

commented May 29, 2018

This thread makes me think. Currently, middlewares handle incoming requests, would it make sense to have a second group of middlewares that handle outgoing responses ? Or instead of incoming/outgoing, it could be beforeEffects/afterEffects.
It would provide easy solutions for cases like handling all 404 responses.

@JozefFlakus

This comment has been minimized.

Copy link
Member

commented May 29, 2018

@couzic but why would we need a second layer for processing outgoing requests? The end of the request lifecycle should be visible inside Effect pipeline which is then processed by the responseHandler. If there would be some need for applying some transformations for sent data then you can simply use use operator for composing it just before final map.

But definitely the custom error.handlers should have an ability to intercept 404 responses in case when no Effect will match the request.

@JozefFlakus JozefFlakus added this to To do in Roadmap to 1.0.0 via automation May 30, 2018

@JozefFlakus JozefFlakus added this to the v0.4.0 milestone May 30, 2018

@JozefFlakus

This comment has been minimized.

Copy link
Member

commented May 30, 2018

@nairihar * matching added in version 0.4.0. You can see the latest changelog here: marblejs.gitbook.io/marble/changelog1

Roadmap to 1.0.0 automation moved this from To do to Done May 30, 2018

@JozefFlakus

This comment has been minimized.

Copy link
Member

commented May 30, 2018

@nairihar here you can find an example implementation for 404 route detection.

In the next days I will update the marblejs.com with detailed description how routing is resolved (introduced in #40).

@couzic

This comment has been minimized.

Copy link

commented May 31, 2018

@JozefFlakus I agree with you, it was just a naive thought. The * solution works for me !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.