- Nov 2022
-
github.com github.com
-
Since Mash is conceived to provide psuedo-object functionality, handling keys which cannot represent a method call falls outside its scope of value.
Tags
Annotators
URL
-
- Sep 2022
-
github.com github.com
-
This issue is for discussing the use case given in the next section, and the unevaluatedProperties proposal to solve it. If you want to discuss a different use case or a different proposal, you MUST file your own issue to do so. Any comments attempting to revive other lines of discussion from #515, introduce new problems or solutions, or otherwise derail this discussion will be deleted to keep the focus clear. Please file a new issue and link back to this one instead.
-
- Aug 2022
-
github.com github.com
-
Out of scope
Tags
Annotators
URL
-
- Jan 2022
-
stackoverflow.com stackoverflow.com
-
The RFC2617 model is one-user, one-credentials so the case where the user may have a second set of credentials that could be authorized may be ignored. It neither suggests nor implies that some sort of login page or other non-RFC2617 authentication protocol may or may not help - that is outside the RFC2616 standards and definition.
-
- Feb 2021
-
github.com github.com
-
Grouped inputs It can be convenient to apply the same options to a bunch of inputs. One common use case is making many inputs optional. Instead of setting default: nil on each one of them, you can use with_options to reduce duplication.
This is just a general Ruby/Rails tip, nothing specific to active_interaction (except that it demonstrates that it may be useful sometimes, and gives a specific example of when you might use it).
Still, in my opinion, this doesn't belong in the docs. Partly because I think repeating the
default: nil
for every item is an acceptable type of duplication, which would be better, clearer (because it's more explicit), simpler, keeps those details closer to the place where they are relevant (imagine if there were 50 fields within awith_options
block).I also think think that it creates a very arbitrary logical "grouping" within your code, which may cause you to unintentionally override/trump / miss the chance to use a different, more logical/natural/important/useful logical grouping instead. For example, it might be more natural/important/useful to group the fields by the section/fieldset/model that they belong with, even if your only
grouping
is a comment:# User fields string :name integer :age date :birthday, default: nil # Food preferences array :pizza_toppings boolean :wants_cake, default: nil
may be a more useful grouping/organization than:
# Fields that are required string :name integer :age array :pizza_toppings # Fields that are optional with_options default: nil do date :birthday boolean :wants_cake end
Or it might be better to list them strictly in the same order as they appear in your model that you are trying to match. Why? Because then you (or your code reviewer) can more easily compare the lists between the two places to make sure you haven't missed any fields from the model, and quickly be able to identify which ones are missing (hopefully intentionally missing).
In other words, their "optionalness" seems to me like a pretty incidental property, not a key property worthy of allowing to dictate the organization/order/grouping of your code.
-
-
-
The basic classification of a form object is a class that contains writable attributes, validations and logic to persist the attributes to ActiveRecord objects. These forms can also include other side-effects like background job triggers, emails, and push-notifications etc. The simplest way to understand the concept is to think of them as a representation of a controller action where all of the business logic that happens in that controller action is abstracted into a form object.
This definition may be a bit too broad. Others (like Reform) define it to have smaller scope — only the part where it persists/validates attributes. The other side effects might be better to put in a different location, like the controller action, or a service/processor object that has a form object.
-
- Sep 2020
-
github.com github.com
-
I don't think we need more tooling here.
-
-
-
I think it'd be nice to find a solution where it's a lot easier to mix React and Svelte components like this, but unfortunately I think that's out of the scope of this library.
-
- May 2020
-
about.gitlab.com about.gitlab.com
-
Out of Scope The following details what is outside of the scope of support for GitLab.com customers with a subscription.
-
The GitLab.com support team does offer support for: Account specific issues (unable to log in, GDPR, etc.) Broken features/states for specific users or repositories Issues with GitLab.com availability
-
Out of Scope The following details what is outside of the scope of support for self-managed instances with a license.
-
-
support.gitlab.com support.gitlab.com
-
Community Forum For free and trial users, or if the question is out of scope.
-