- Sep 2024
-
www.mikeperham.com www.mikeperham.com
-
This makes developing a modern daemon much easier. The init config file is what you use to configure logging, run as a user, and many other things you previous did in code. You tweak a few init config settings; your code focuses less on housekeeping and more on functionality.
-
-
www.gertgoet.com www.gertgoet.com
-
# booleans # simple: providing any value for ENV['FORCE_SSL'] means `true`: force_ssl = !!ENV['FORCE_SSL'] # more advanced: # only when we provide 'true' will `force_ssl` become true. force_ssl = ('true' == ENV['FORCE_SSL'])
-
- Aug 2022
-
-
Reducing nested structures is tiresome. Have you tried immer?
-
- Jun 2022
-
thoughtbot.com thoughtbot.com
-
With first-class keyword arguments in the language, we don’t have to write the boilerplate code to extract hash options. Unnecessary boilerplate code increases the opportunity for typos and bugs.
-
- Feb 2022
-
github.com github.com
-
The goal of this gem is to reduce the amount of code that needs to be written when developing a ruby on rails website.
-
- Jan 2022
-
-
Boilerplate is only boilerplate if it's the same everywhere, which it shouldn't be.
-
and if I think this is too boilerplatey, I can export a handler from some .js file and pass the error to that: <script> import { onError } from 'svelte' import { genericHandler } from '../my-error-handler.js' onError(genericHandler(e => { // code which is called first to try to handle this locally return true // we've handled it here, don't do anything else. }) </script>
-
- Sep 2021
-
www.sanity.io www.sanity.io
-
React, on the other hand, often requires a fair amount of boilerplate code, even for simple interactions.
-
- Aug 2021
-
stackoverflow.com stackoverflow.com
-
That should work as expected and not be too verbose (or at least it doesn't repeat string literals anywhere)
-
So is @Ryan Cavanaugh's answer the only viable solution? It seems extremely verbose...
-
- Jun 2021
-
stackoverflow.com stackoverflow.com
-
Which gets the job done, but that's a chunk of boilerplate for a simple accessor
-
-
disqus.com disqus.com
-
I like auto-property generation... who needs boilerplate code?
-
- Mar 2021
-
www.jackfranklin.co.uk www.jackfranklin.co.uk
-
Coming from React to Svelte this did catch me out numerous times but for me I now prefer Svelte's approach, particularly because it removes some of the boilerplate around useEffect.
-
Here's where I start to have a preference for Svelte; the two are very similar but once I got used to Svelte I found that React felt like jumping through hoops. You can't create a worker instance, it has to go in a useRef, and then you can't easily pull code out into a function without then requiring useCallback so it can be a safe dependency on useEffect. With Svelte I write code that's closer to "plain" JavaScript, whereas in React more of my code is wrapped in a React primitive.
-
- Feb 2021
-
trailblazer.to trailblazer.to
-
To understand this helper, you should understand that every step invocation calls Output() for you behind the scenes. The following DSL use is identical to the one [above]. class Execute < Trailblazer::Activity::Railway step :find_provider, Output(Trailblazer::Activity::Left, :failure) => Track(:failure), Output(Trailblazer::Activity::Right, :success) => Track(:success)
-
For branching out a separate path in an activity, use the Path() macro. It’s a convenient, simple way to declare alternative routes
Seems like this would be a very common need: once you switch to a custom failure track, you want it to stay on that track until the end!!!
The problem is that in a Railway, everything automatically has 2 outputs. But we really only need one (which is exactly what Path gives us). And you end up fighting the defaults when there are the automatic 2 outputs, because you have to remember to explicitly/verbosely redirect all of those outputs or they may end up going somewhere you don't want them to go.
The default behavior of everything going to the next defined step is not helpful for doing that, and in fact is quite frustrating because you don't want unrelated steps to accidentally end up on one of the tasks in your custom failure track.
And you can't use
fail
for custom-track steps becase that breaksmagnetic_to
for some reason.I was finding myself very in need of something like this, and was about to write my own DSL, but then I discovered this. I still think it needs a better DSL than this, but at least they provided a way to do this. Much needed.
For this example, I might write something like this:
step :decide_type, Output(Activity::Left, :credit_card) => Track(:with_credit_card) # Create the track, which would automatically create an implicit End with the same id. Track(:with_credit_card) do step :authorize step :charge end
I guess that's not much different than theirs. Main improvement is it avoids ugly need to specify end_id/end_task.
But that wouldn't actually be enough either in this example, because you would actually want to have a failure track there and a path doesn't have one ... so it sounds like Subprocess and a new self-contained ProcessCreditCard Railway would be the best solution for this particular example... Subprocess is the ultimate in flexibility and gives us all the flexibility we need)
But what if you had a path that you needed to direct to from 2 different tasks' outputs?
Example: I came up with this, but it takes a lot of effort to keep my custom path/track hidden/"isolated" and prevent other tasks from automatically/implicitly going into those steps:
class Example::ValidationErrorTrack < Trailblazer::Activity::Railway step :validate_model, Output(:failure) => Track(:validation_error) step :save, Output(:failure) => Track(:validation_error) # Can't use fail here or the magnetic_to won't work and Track(:validation_error) won't work step :log_validation_error, magnetic_to: :validation_error, Output(:success) => End(:validation_error), Output(:failure) => End(:validation_error) end
puts Trailblazer::Developer.render o Reloading... #<Start/:default> {Trailblazer::Activity::Right} => #<Trailblazer::Activity::TaskBuilder::Task user_proc=validate_model> #<Trailblazer::Activity::TaskBuilder::Task user_proc=validate_model> {Trailblazer::Activity::Left} => #<Trailblazer::Activity::TaskBuilder::Task user_proc=log_validation_error> {Trailblazer::Activity::Right} => #<Trailblazer::Activity::TaskBuilder::Task user_proc=save> #<Trailblazer::Activity::TaskBuilder::Task user_proc=save> {Trailblazer::Activity::Left} => #<Trailblazer::Activity::TaskBuilder::Task user_proc=log_validation_error> {Trailblazer::Activity::Right} => #<End/:success> #<Trailblazer::Activity::TaskBuilder::Task user_proc=log_validation_error> {Trailblazer::Activity::Left} => #<End/:validation_error> {Trailblazer::Activity::Right} => #<End/:validation_error> #<End/:success> #<End/:validation_error> #<End/:failure>
Now attempt to do it with Path... Does the Path() have an ID we can reference? Or maybe we just keep a reference to the object and use it directly in 2 different places?
class Example::ValidationErrorTrack::VPathHelper1 < Trailblazer::Activity::Railway validation_error_path = Path(end_id: "End.validation_error", end_task: End(:validation_error)) do step :log_validation_error end step :validate_model, Output(:failure) => validation_error_path step :save, Output(:failure) => validation_error_path end
o=Example::ValidationErrorTrack::VPathHelper1; puts Trailblazer::Developer.render o Reloading... #<Start/:default> {Trailblazer::Activity::Right} => #<Trailblazer::Activity::TaskBuilder::Task user_proc=validate_model> #<Trailblazer::Activity::TaskBuilder::Task user_proc=validate_model> {Trailblazer::Activity::Left} => #<Trailblazer::Activity::TaskBuilder::Task user_proc=log_validation_error> {Trailblazer::Activity::Right} => #<Trailblazer::Activity::TaskBuilder::Task user_proc=save> #<Trailblazer::Activity::TaskBuilder::Task user_proc=log_validation_error> {Trailblazer::Activity::Right} => #<End/:validation_error> #<Trailblazer::Activity::TaskBuilder::Task user_proc=save> {Trailblazer::Activity::Left} => #<Trailblazer::Activity::TaskBuilder::Task user_proc=log_validation_error> {Trailblazer::Activity::Right} => #<End/:success> #<End/:success> #<End/:validation_error> #<End/:failure>
It's just too bad that:
- there's not a Railway helper in case you want multiple outputs, though we could probably create one pretty easily using Path as our template
- we can't "inline" a separate Railway acitivity (Subprocess "nests" it rather than "inlines")
Tags
- demystified
- useful
- helper functions
- flexibility
- verbose / noisy / too much boilerplate
- being explicit
- powerful
- automatic
- concise
- tip
- equivalent code
- example: not how you would actually do it (does something wrong/bad/nonideal illustrating but we should overlook it because that's not the one thing the example is trying to illustrate/show us)
Annotators
URL
-
-
trailblazer.to trailblazer.to
-
The sole purpose to add Dev::Trace::Inspector module is to make custom inspection possible and efficient while tracing. For example, ActiveRecord::Relation#inspect makes additional queries to fetch top 10 records and generate the output everytime. To avoid this, Inspector will not call inspect method when it finds such objects (deeply nested anywhere). Instead, it’ll call AR::Relation#to_sql to get plain SQL query which doesn’t make additional queries and is better to understand in tracing output.
-
-
jrsinclair.com jrsinclair.com
-
As you can see, we end up with a lot of boilerplate if-statements. The code is more verbose. And it’s difficult to follow the main logic.
-
-
en.wikipedia.org en.wikipedia.org
-
it is inconvenient to write specific implementations for each datatype contained, especially if the code for each datatype is virtually identical. For example, in C++, this duplication of code can be circumvented by defining a class template
-
-
en.wikipedia.org en.wikipedia.org
-
Supporting languages may use monads to abstract away boilerplate code needed by the program logic.
-
-
trailblazer.to trailblazer.to
-
They help streamlining the control flow, and take away control code while providing you with an incredibly cool developer experience.
-
-
github.com github.com
-
account.first_name = first_name if first_name.present? account.last_name = last_name if last_name.present?
I guess this is needed so we don't reset to nil (erasing value in database) when they haven't even provided a new value as input.
But surely there's a cleaner way...
-
- Jan 2021
-
stackoverflow.com stackoverflow.com
-
Also, you'll get more concise code. More boilerplate left handling by the machine means more available human for the actual logic.
-
- Nov 2020
-
stackoverflow.com stackoverflow.com
-
If you were to check the return status of every single command, your script would look like this:
Illustrates how much boilerplate set -e saves you from.
Update: Oops, if you read a comment further below, you learn that:
Actually the idiomatic code without
set -e
would be justmake || exit $?
True that.
-
- Oct 2020
-
github.com github.com
-
Compare that with the current recommended way to add/remove fields in an array, which is very verbose and boilerplatey:
-
-
tech.ebayinc.com tech.ebayinc.com
-
Writing a logic-less template requires a bloated view model with comprehensive getters for the raw data. As a result, a messy and difficult-to-maintain view model usually accompanies logic-less templates.
-
-
-
This is exactly why I'm in favor of @const. Helpers are fine, except when they're not and turn into boilerplate.
-
always end up with a boilerplate function somewhere, which feels hacky.
-
-
dylanvann.com dylanvann.com
-
The Svelte compiler does the dependency tracking work for us, so there’s no dependency array like in React.
-
-
recoiljs.org recoiljs.org
-
We get a boilerplate-free API where shared state has the same simple get/set interface as React local state (yet can be encapsulated with reducers etc. if needed).
-
-
github.com github.com
-
Comparison to useReducer
-
This library is built in TypeScript, and for TypeScript users it offers an additional benefit: one no longer needs to declare action types. The example above, if we were to write it in TypeScript with useReducer, would require the declaration of an Action type: type Action = | { type: 'reset' } | { type: 'increment' } | { type: 'decrement' }; With useMethods the "actions" are implicitly derived from your methods, so you don't need to maintain this extra type artifact.
-
- Sep 2020
-
github.com github.com
-
It would be tiresome - and bloated - to include a class pass-through for every component or assigning custom properties (from the RFC linked) for all potential properties on every component, just in case it's gonna be used in layouts that requires it. Wrapping them in a wrapper div is certainly an option, but potentially creates 100s or 1000s (long lists, several lists etc.) of new elements in the DOM slowing down low-end devices.
-
-
-
currently it's definitely possible from the user side but it requires some boilerplate code that we could move to svelte.
Tags
Annotators
URL
-
-
daveceddia.com daveceddia.com
-
Seems like an awful lot of typing to make a simple input control, especially when Angular did all that for you.
-
- Aug 2020
-
svelte.dev svelte.dev
-
It starts to get a bit boilerplatey though, especially if your component subscribes to multiple stores.
-
- Jul 2020
-
svelte.dev svelte.dev
-
Take the case of the <input> element in this component — we could add an on:input event handler that sets the value of name to event.target.value, but it's a bit... boilerplatey
-
- Jun 2020
-
www.reddit.com www.reddit.com
-
I was just expressing that, even thought I like React, I dread having to still manually handle everything, instead of just using a directive, a la Vue.JS. This is what I consider boilerplate. Hence my comment on how I could leave React for Svelte just because of that. Clearly a Svelte side-by-side code comparison shows a much cleaner code for Svelte.
-
Man, just because it gets rid of SO MUCH boilerplate I want to switch already.It kills me everytime I work with forms in React. So much noise for such a simple task.
-
- Dec 2019
-
master.neutrinojs.org master.neutrinojs.org
Tags
Annotators
URL
-