Refactor Fuel to make it more extensible
See original GitHub issueI really like Fuel but I think the existing design doesn’t allow for easy extension. Here’re some design suggestions that, IMO, will make the library a lot more user friendly and also reduce code. Thoughts?
- Users should be able to use any encoder, decoder, HTTP client they want using the builder pattern on
Fuel
, like so:
Fuel.builder.build() // creates Fuel with all default settings
Fuel.builder
.encoder(FuelJacksonEncoder())
.build() // creates Fuel with Jackson encoder and rest default
Fuel.builder
.encoder(FuelJacksonEncoder())
.client(FuelOkHttpClient())
.build() // you get the idea
Each of the components FuelJacksonEncoder
etc also follows the same builder pattern.
-
Do away with the
String.*
extension methods. You always start with aFuel
instance as shown above, plain and simple. -
The
Triple
is kind of confusing, because theResult
is sort of forced on the user. When I make a HTTP request, I expect a response, and thank you for also providing the request at the same time. If I didn’t ask you for aResult
object, don’t force it on me.
fuel.get("http://httpbin.org/get")
.response { request, response ->
// response.body would be Array<Byte>
// response.bodyAs<T> would use the decoder to convert to T, where T can be, but not limited to, InputStream
// response.as<Result> would convert the response to a Result object provided result module is in compile scope. If not this code wouldn't compile.
}
- Do away with
responseString
andresponseJson
as point 3 above is enough.
Issue Analytics
- State:
- Created 6 years ago
- Reactions:2
- Comments:11 (2 by maintainers)
Top Results From Across the Web
How to refactor this legacy code snippet to make it extensible?
First thing I consider is that it is quite feasible to write automated tests for it. You should definitely do it before you...
Read more >Design Debt - C2 wiki
Of course, DesignDebt will increase if you do not refactor, until the cost of adding new features is greater than it would be...
Read more >When should you not refactor? - Stack Overflow
Given code with no tests, you may refactor it to to make it more testable. ... have better flow, and are more extensible...
Read more >Tips for avoiding refactoring paralysis? : r/SatisfactoryGame
Here's a tip for satisfactory and software development. Just work on the problem you actually have, not in problems you might have in...
Read more >Test-driven development - IBM Garage Practices
Your specific code become more general. The unit tests provide a safety net which supports the refactoring, because they make sure that the...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Works now. Let’s close this and re-open separate tickets if we want to implement https://github.com/kittinunf/Fuel/issues/225#issuecomment-328327731
My Idea:
FuelBuilder / FuelManager:
Fuel class + Fuel companion object:
FuelManager
and provides more friendly API for request.Fuel
instance from providedFuelManager
.Fuel
hascompanion object: Fuel
that hasFuelManager
mutable field. So you could just callFuel.get(...)
if you need only a singleFuel
instance.Request + MutableRequest:
Future
,SSLSocketFactory
…).FuelManager
config (headers, parameters, ssl,…) will be injected onClient
.FuelManager
). Maybe will have a internal field withFuelManager
instance, and a public method onFuel
classfun apply(request: Request): MutableRequest
(which will replace the instance).MutableRequest
interface which you receive fromFuel.method(...)
and is mutable. theRequest
you receive fromresponseX {}
is immutable.MutableRequest
will become extension methods, though they will still be the preferred way to mutate a request.MutableRequest
as builder:Request flow:
FuelManager
instance.Fuel
instance from (1).fuel.method()
on (2) instance to getMutableRequest
instance and mutate it.responseX()
on (3) instance.FuelManager
instance (1) and theMutableRequest
(3) to a singleRequest
.Client
of (1) for executing.Javascript support #134: Now it will be really easy to support Javascript.
FuelManager
anheader
class.impl
classes for each platform.Client
for each platform.ResponseDeserializable
can also be different on each platform.Environment
can be changed fromcallbackExecutor: Executor
tofun callCallback(callback)
.Should work 👋