Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

'Fluent API' Recipe Builder syntax

See original GitHub issue

Description

An extension coupled with a RecipeBuilder class, allowing for easier recipe building. The current implementation is in my library and works fine, although I assume it would need some adjusting to fit tML standards.

What does this proposal attempt to solve or improve?

The way recipes are added right now is not exactly the most pleasant, albeit not atrocious. This syntax aims to solve the issue by providing some kind of ‘natural language’ implementation to recipes added in AddRecipes.

Which (other) solutions should be considered?

I am unaware of any other solutions such as this one, other than Mirsario’s.

Examples

Here are two examples that show what the syntax could be. The first example instantiates a new RecipeBuilder manually.

The second example uses both the extension method and multiple crafting stations

The current implementation has several other methods which I’ve not included in this issue, but are as follows:

SetResult: calls SetResult for the recipe
SetResultStack: changes only the amount produced, useful in case of multiple recipes producing the same item but not the same quantity
Several instances of New, which take different parameters. New will automatically call Finish on an old recipe if its not been added to the game
Clear: effectively calls New with the existing information. Not named New since it only works if you already have an existing product in the builder
The different constructors for RecipeBuilder (which all follow the different SetResult for ModRecipe)

Issue Analytics

State:
Created 3 years ago
Reactions:1
Comments:11 (6 by maintainers)

Top GitHub Comments

1reaction

Jofairdencommented, May 1, 2020

Yeah that’s not how the builder pattern works When you call ‘Build()’, that’s the final step. Any other step is possible at any moment before building. In case you’re wondering, the fluent API pattern is almost always used alongside the builder pattern, and it makes perfect sense. In short, you should be able to construct the recipe in any order.

1reaction

Jofairdencommented, May 1, 2020

One recipe builder instance should build one recipe. 1 <-> 1 relation

So ModRecipeBuilder.Build() should return a ModRecipe If you want to make a new recipe, you then go again: new ModRecipeBuilder().Requires(..)..At(...).Build();

Anywhere sounds quite redundant since you don’t require a tile, what does that even do?

Top Results From Across the Web

Fluent API: Practice and Theory

The class StringBuilder has a fluent API, which means its methods can ... In fluent APIs that follow this recipe, the imperative and...

Fluent API - Configuring and Mapping Properties and Types

The following example shows how to specify that a property on a CLR type is not mapped to a column in the database....

Code first fluent api syntax - Fluent Entity Framework [Book]

Here's a basic example of the real syntax. Image. public class RecipeContext : DbContext{ public DbSet<Recipe> Recipes {get; set;} protected override void ...

Introduction - Fluent Assertions

This enables a simple intuitive syntax that all starts with the following using statement: using FluentAssertions; ... var recipe = new RecipeBuilder() ....

The Java Fluent API Designer Crash Course

– Context / Builders / Factories are implementation-specific problems. I tend to solve this either by avoiding static methods (and create the ...