# 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'])

--stop-after-configfile-check

# Note that it could be in `args.first`, or in `kwargs[:id]` now, so it is either this: def initialize(*args, **kwargs) if !args.empty? args[0] = args[0].to_i elsif kwargs.key?(:id) kwargs[:id] = kwargs[:id].to_i end super(*args, **kwargs) end

Rails' default approach to log everything is great during development, it's terrible when running it in production. It pretty much renders Rails logs useless to me.

Lograge is an attempt to bring sanity to Rails' noisy and unusable, unparsable and, in the context of running multiple processes and servers, unreadable default logging output.

So far for the obligatory warning. I get the point, I even agree with the argument, but I still want to send a POST request. Maybe you are testing an API without a user interface or you are writing router tests? Is it really impossible to simulate a POST request with Capybara? Nah, of course not!

This is ugly by design, as an inducement to test properties instead of specifics.

Reducing nested structures is tiresome. Have you tried immer?

Content in the wild can easily come to rely on this: var underAutomation = ("webdriver" in navigator) ? navigator.webdriver : false; v, without this behaviour: var underAutomation = navigator.webdriver;

But it is kind of verbose, and it’s also a lot slower, so I can understand why the model test might be preferred.

React, on the other hand, often requires a fair amount of boilerplate code, even for simple interactions.

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...

Which gets the job done, but that's a chunk of boilerplate for a simple accessor

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.

Pluggability uses the Loggability library. Just set the log level to 'debug' and it'll explain what's going on:

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

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

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>

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>

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.

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.

account.first_name = first_name if first_name.present? account.last_name = last_name if last_name.present?

this second approach, while more verbose, sort of spells out better where things are coming from. (I like it, in other words.)

Compare that with the current recommended way to add/remove fields in an array, which is very verbose and boilerplatey:

hyperscript is more concise because it's just a function call and doesn't require a closing tag. Using it will greatly simplify your tooling chain.

Template literals work well for long embedded DSLs. Unfortunately the syntax noise is substantial when you exit in and out of embedded arbitrary ECMAScript expressions with identifiers in scope.

But this is starting to become rather verbose at what could be a much simpler and more elegant solution if only there were another template helper that could do variable assignment.

always end up with a boilerplate function somewhere, which feels hacky.

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.

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.

verbosity for multiple overrides in parent component markup

variables and fallbacks in the child component css again seem verbose, and not as flexible as classes

Your tooltip component will have to wrap your image with a span tag or something, it can’t just add events to its children. And if you are adding multiple actions to it you will have to wrap it multiple times.

<Concern1> <Concern2> </Concern2> </Concern1>

vs.

<img use:concern1 use:concern2>

Three tests to prove a small piece of behavior. Although it might seem overkill for such a small feature, these tests are quick to write—that is, once you know how to write them

I have considered taking the selector :global(childSelector){} but it is far too verbose

There are tools in Svelte that break this expectation to a degree, but they are a bit annoying to use, which makes it an active decision on the part of the developer. The API hints at the way we want you to do things because we feel that this will give the better experience.

Seems like an awful lot of typing to make a simple input control, especially when Angular did all that for you.

It starts to get a bit boilerplatey though, especially if your component subscribes to multiple stores.

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

Besides, this will just end up being reported as a security bug to the security list if left as is, cause docker will eat up all your disk space due to a single call site flooding STDERR forcing logs to grow forever.

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.