pixeltopic / sayori Goto Github PK

Currently, the route matching does not handle duplicate aliases well in subroutes due to the matching algorithm.

Assume there is a route root

Two subroutes A and B are added to root as subcommands in this order. They both have the same aliases, foo.
However, B's subroute has another subroute (let's call it C). C has an alias bar.

A message comes in: foo bar

Because of the current match algorithm, route A will be found first, and route B, which has the same alias, will not be considered.

After the algorithm rewrite, the "greedy" aspect of this algorithm will be lessened, but not eliminated. The algorithm will instead select the newest added route B because

1. It is newer
2. It is a better match (will match foo bar instead of just foo)

Depth may be reported inaccurately if a command contains 1 token which is an alias. Investigate this and modify the findRoute function if it occurs.

Sayori currently supports preset filters. However, it should also support filters that accept custom callbacks - "middlewares".

Each Command or Event can have 0 or more custom middlewares appended using Builder. These middlewares are run sequentially after Filter is processed.

A middleware function signature comes in the form of func(Context) error.

Tentative. If a user wants to implement a subcommand, they just need to specify an alias with a space in it:

rootcommand subcommand

The Match function should account for this and in makeCommand it should do strings.Fields to split the command and subcommand by whitespace before storing them in an ordered string slice within Context.

Right now Resolve is forced to be implemented after Handle runs. In order to make this less opinionated, Resolve should be an optional function that will be checked after handle is run using an interface type assertion. If Resolve is not implemented, any errors produced by Handle will be subsumed.

Currently when a Route is added, there is no way to remove them. New fix adds a func() return type which will remove the handler when called.

Routes are added into the router using a pointer when they should be passed by value. This would mean that attempting to change aliases, middlewares, and subroutes will remain consistent throughout the Route lifetime. However, this will not protect against:

• any future fields in Route that use a map
• the handler type's internal state from being changed
• the prefixer's internal state from being changed

This was mistakenly added when I was working on the subroute searching algorithm because I thought I had to skip the prefix trimming for every route after the root route.

This should be unnecessary - a Prefixer (if nil) will return an empty string. If a given Prefixer also returns an empty string, we don't need to differentiate this because they are functionally the same.

v2 lacks a detailed README. When this is complete an initial release can be cut for v2.