URI::MailTo::EMAIL_REGEXP
First time I've seen someone create a validator by simply matching against URI::MailTo::EMAIL_REGEXP from std lib. More often you see people copying and pasting some really long regex that they don't understand and is probably not loose enough. It's much better, though, to simply reuse a standard one from a library — by reference, rather than copying and pasting!!
In combination with [Track()], the :magnetic_to option allows for a neat way to spawn custom tracks outside of the conventional Railway or FastTrack schema.
Instead of magnetic_to:, I propose wrapping the steps that are on a separate track in something like...
DefTrack do :paypal do
step :charge_paypal
end
or
paypal_track = RailwayTrack do :paypal do
step :charge_paypal
end
so we can reference it from outputs, like we can with tracks created with Path helper.
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 breaks magnetic_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:
step :direct_debit
I don't think we would/should really want to make this the "success" (Right) path and :credit_card be the "failure" (Left) track.
Maybe it's okay to repurpose Left and Right for something other than failure/success ... but only if we can actually change the default semantic of those signals/outputs. Is that possible? Maybe there's a way to override or delete the default outputs?
Patching has no implicit, magical side-effects and is strongly encouraged to customize flows for a specific case in a quick and consise way.
While you could nest an activity into another manually, the Subprocess macro will come in handy.
The macro automatically wires all of Validate’s ends to the known counter-part tracks.
Sure, zero-config one-click installs are nice and all, but:
It's recommended to configure this library by setting environment variables.
despite initially appearing to be an appropriate and effective response to a problem, has more bad consequences than good ones
Do notation provides an alternative to bind, which also flattens the code.
They do not maintain a to-do list (mentally or physically).
If you ask my former students, they will tell you that as a teacher, my goal is to do nothing. I dream of the day when I can sit at my desk, feet propped up, reading a book, while the classroom bursts with activity and learning around me.
While Trailblazer offers you abstraction layers for all aspects of Ruby On Rails, it does not missionize you. Wherever you want, you may fall back to the "Rails Way" with fat models, monolithic controllers, global helpers, etc. This is not a bad thing, but allows you to step-wise introduce Trailblazer's encapsulation in your app without having to rewrite it.
The new 2.1 version comes with a few necessary but reasonable changes in method signatures. As painful as that might sound to your Rails-spoiled ears, we preferred to fix design mistakes now before dragging them on forever.
ActiveModel provides a powerful framework for defining callbacks. ActiveInteraction hooks into that framework to allow hooking into various parts of an interaction's lifecycle.
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...
Personal todo lists don’t depend on others using the same system (no network effects)
They don't unless you're building a wiki or commonplace book that can interact with those of others. (Roam research isn't doing this---yet, but they should.) Ideally small building block pieces will allow it to dovetail with other systems that could potentially do the same thing.
{a: 1, b: 2, c: 3, d: 4} => {a:, b:, **rest} # a == 1, b == 2, rest == {:c=>3, :d=>4}
equivalent in javascript:
{a, b, ...rest} = {a: 1, b: 2, c: 3, d: 4}
Not a bad replacement for that! I still find javascript's syntax a little more easily readable and natural, but given that we can't use the same syntax (probably because it would be incompatible with existing syntax rules that we can't break for compatibility reasons, unfortunately), this is a pretty good compromise/solution that they've come up with.
In order to support easy reuse, revision, remixing, and redistribution, the entire Hypothesis Help knowledge base by Hypothesis is dedicated to the public domain via CC CC0 1.0. While we appreciate attribution and links back to Hypothesis from anywhere these works are published, they are not required.
Examples of different ways of defining forms
Wow, that's a lot of different ways.
The inline_form way in particular seems interesting to me, though it's worth noting that that method is just an example, not actually part of this project's code, so it's not really a first-class option like the other options.
The assert method is used by all the other assertions. It pushes the second parameter to the list of errors if the first parameter evaluates to false or nil.
Seems like these helper functions could be just as easily used in ActiveRecord models. Therefore, they should be in a separate gem, or at least module, that can be used in both these objects and ActiveRecord objects.
The more important point comes from a program design perspective. Here, "programming to an interface" means focusing your design on what the code is doing, not how it does it. This is a vital distinction that pushes your design towards correctness and flexibility.
It makes me happy to see people actually think about things and not just accept a shitty API.
I'd like to know specifically what you were aiming to achieve with this Gem as opposed to simply using https://github.com/apotonick/reform? I am happy to help contribute, but equally if there is a gem out there that already does the job well, I'd like to know why we shouldn't just use that.
DSLs can be problematic for the user since the user has to manage state (e.g. am I supposed to call valid? first or update_attributes?). This is exactly why the #validate is the only method to change state in Reform.
The reason Reform does updating attributes and validation in the same step is because I wanna reduce public methods. This is to save users from having to remember state.
I see what he means, but what would you call this (tag)? "have to remember state"? maybe "have to remember" is close enough
Or maybe order is important / do things in the right order is all we need to describe the problem/need.
Writing the uniqueness validations yourself is easy so I felt it was better to leave this up to the developer
This is what seems to be happening to me as well! It's maddening.
p. 217:
We also keep a higher percentage of our assets in cash than most financial advisors would recommend --- something around 20% of the value of our assets outside the value of our house.
Compare this to my current allotment.
Yes, you do face difficult choices (moral) but you don't care about it. All you care are the reputation bars. So... Let's kill this guy, who cares if he is innocent, but this faction needs it or I'm dead. Sounds great on paper but to be honest... you just sit there and do whatever for these reputation bars. If you won't, then you lose
We could of course refactor our code to rename things any time we like, but we don’t do this enough in practice
considering PopOS is trying to tackle Ubuntu they really need their dual-boot setup to be a lot less tedious
if PopOS! really wants to be what Ubuntu was 10 years ago they need to step up and make dual booting easier.
that's a point, but I would say the opposite, when entering credit card data I would rathre prefer to be entirely in the Verified By Visa (Paypal) webpage (with the url easily visible in the address bar) rather that entring my credit card data in an iframe of someone's website.
Systemd flies in the face of the Unix philosophy: 'do one thing and do it well,' representing a complex collection of dozens of tightly coupled binaries
systemd has such huge documentation. systemd.unit Did you try searching for explanation yourself? What did you find?
http://letmegooglethat.com/?q=How+to+change+the+default+search+engine+in+chromium&l=1
I want to write my own scripts first, but may end up graduating to this.
overflow-wrap: break-word; makes sure the long string will wrap and not bust out of the container. You might as well use word-wrap as well because as the spec says, they are literally just alternate names for each other. Some browsers support one and not the other.
I'm very (VERY!) tempted to use that ppa, but without offense to it's maintainers... it's just some random ppa. If it had more "traction" I'd use it. Right now it has only 3 maintainers.
Flatpak as a truly cross-distro application solution that works equally well and non-problematic for all
The purpose of news is to inform, educate, and give us understanding and knowledge of what is going on in the world. It helps us to keep up to date with issues so we are in the know and fully aware of events taking place.
Moving DOM elements around made me anxious and I wanted to preserve natural tab order without resorting to setting tabindex, so I also made a flexbox version that never moves DOM elements around. I think it's the superior solution, at least for the layouts I was going for. https://github.com/wickning1/svelte-components/blob/master/src/FlexCardLayout.svelte
Depending on what other component libraries you’ve used, you may be used to handling events by passing callback functions to component properties, or using a special event syntax – Svelte supports both, though one is usually more appropriate than the other depending on your situation. This post explains both ways.
You should default to the most permissive option imo and there really is no reason to check anything until you really need to If it were left to me I'd just use optional chaining, as it also eliminates the need for no-ops
(lazy checking)
In other words, programs that send messages to other machines (or to other programs on the same machine) should conform completely to the specifications, but programs that receive messages should accept non-conformant input as long as the meaning is clear.
be conservative in what you do, be liberal in what you accept from others
"Headless Tippy" refers to Tippy without any of the default element rendering or CSS. This allows you to create your own element from scratch and use Tippy for its logic only.
It's a generic abstraction for the logic and styling of elements that pop out from the flow of the document and float next to a reference element, overlaid on top of the UI.
A cleaner approach could be the use:action API.
See more at: https://hyp.is/2cvibFXNEeuMw9viXh_i6g/github.com/bryanmylee/svelte-popperjs
Popper has a sole goal: position elements. That's why we call it a "positioning engine" and not a "tooltip library".
Popper for Svelte with actions, no wrapper components or component bindings required! Other Popper libraries for Svelte (including the official @popperjs/svelte library) use a wrapper component that takes the required DOM elements as props. Not only does this require multiple bind:this, you also have to pollute your script tag with multiple DOM references. We can do better with Svelte actions!
Progress is made of compromises, this implies that we have to consider not only disadvantages, but also the advantages. Advantages do very clearly outweigh disadvantages. This doesn’t mean it perfect, or that work shouldn’t continue to minimize and reduce the disadvantages, but just considering disadvantages is not the correct way.
How do you know this? I've looked all over the internet and can't find any proof that Lightdm is more "lightweight" (whatever this means) or faster.
I'd like to spin up a couple of these, both for my personal box (localhost-only) and for the development network.
O tucano Orlando Morando, de São Bernardo do Campo, diz que não há a menor chance de fazê-lo em um futuro próximo e que tem doado parte de seu salário correspondente a um aumento concedido na gestão anterior com o qual não concordou.
Doou para quem???
Heading hierarchy. Don't skip heading levels. In order to solve this problem, you need to separate the semantics from the style.
Dropped FFmpeg support (focus on primary functions instead)
Add this to my toolchain (in particular, configure Lighthouse to run in our CI/CD pipeline).
I really want to wire this up to our heavy-duty internal apps, like CI, Disputes, and NoteRequest.
you can set up notifications to alert you to new recommendations
Jbuilder gives you a simple DSL for declaring JSON structures that beats manipulating giant hash structures. This is particularly helpful when the generation process is fraught with conditionals and loops.
The Web Storage API provides mechanisms by which browsers can store key/value pairs, in a much more intuitive fashion than using cookies.
I guess it's about "preloading" and not "navigation", if it's the case, then I guess there is still no way to attach to navigation events, and this issue should be kept open.
No JS event is fired, so there currently isn't any clean way to do this that I can see.
I tried leaking session and page data and indeed it's easy. Too easy. So I definitely agree that session data should not be readable from anywhere but the request itself.
Like JSON.stringify, but handles
it focuses on compiling non-standard language extensions: JSX, TypeScript, and Flow. Because of this smaller scope, Sucrase can get away with an architecture that is much more performant but less extensible
Phantom emotionsPsychological determinants of emotional experiences on the InternetAzy Barak
You can afford to make a proper PR to upstream.
No more waiting around for pull requests to be merged and published. No more forking repos just to fix that one tiny thing preventing your app from working.
This could be both good and bad.
potential downside: If people only fix things locally, then they may be less inclined/likely to actually/also submit a merge request, and therefore it may be less likely that this actually (ever) gets fixed upstream. Which is kind of ironic, considering the stated goal "No more waiting around for pull requests to be merged and published." But if this obviates the need to create a pull request (does it), then this could backfire / work against that goal.
Requiring someone to fork a repo and push up a fix commit -- although a little extra work compared to just fixing locally -- is actually a good thing overall, for the community/ecosystem.
Ah, good, I see they touched on some of these points in the sections:
Some devs prefer Svelte’s minimal approach that defers problems to userland, encouraging more innovation, choice, and fragmentation, and other devs prefer a more fully integrated toolkit with a well-supported happy path.
tag?: what scope of provided features / recommended happy path is needed?
It’s worth mentioning that Svelte limits its scope to being only a UI component framework. Like React, it provides the view layer, but it has more batteries included with its component-scoped CSS and extensible stores for state management. Others like Angular and Vue provide a more all-in-one solution with official routers, opinionated state management, CLIs, and more. Sapper is Svelte’s official app framework that adds routing, server-side rendering, code splitting, and some other essential app features, but it has no opinions about state management and beyond. Some devs prefer Svelte’s minimal approach that defers problems to userland, encouraging more innovation, choice, and fragmentation, and other devs prefer a more fully integrated toolkit with a well-supported happy path.
tag?: what scope of provided features / recommended happy path is needed?
It’s worth mentioning that Svelte limits its scope to being only a UI component framework. Like React, it provides the view layer, but it has more batteries included with its component-scoped CSS and extensible stores for state management.
If you'd prefer, you can use a third-party library like Modernizr or Detect It to do this test for you.
I think the main difference between the two are the way API are served. Some smelte components need you to input big chunk of json as props, while i prefer keep props as primitive types and in the other hand give you different components tags to compose.
I'd really like to take this.
These are sequential because build:ssr imports the public/index.html that build:dom produces.
p. 198:
Given any five points on a sphere, show that some four of them lie on a hemisphere that includes its boundary.
I'll admit, I already looked at the hint for this problem, and yes, my initial approach did indeed consist of trying to find the 'worst' configuration.
I can think of two ways to determine whether or not two points on a sphere lie within the same hemisphere:
One other note:
So, I have a picture in my mind of the sphere divided into eight regions of equal area by way of three great circles which intersect one another at right angles. (Think the Equator, the Prime Meridian, and a third great circle drawn through the poles at 90 degrees longitude.) My thinking now tends more toward combinatorics and the pigeonhole principle than geometry proper.
The answer should be: you write a language that compiles to Go’s IR.
delete myObject.regex; // or, delete myObject['regex']; // or, var prop = "regex"; delete myObject[prop];
dfn export for=tree
After i've stabilized the library i can start to discuss about adding new components and features!
Svelte makes the pit of success larger because it hides all of this from us at compile time.
Another difference is that context in Svelte does not insert anything into the visual component tree. There is no <Context.Provider> element like in React
I'd love to take this for a spin. Maybe I could rewrite Demeter or micdrop using it.
So handling the interop upfront will avoid users writing invalid ES6 and make sure that they write ES6 that loads CommonJS in the right way.
If everyone did this, the repair shops would be out of business.
This nested if blocks seems a bit untidy and confusing to me but I've also failed to come up with a clearer way.
i like working on application frameworks, compilers, interpreters, and emulators.
but know I know what I don't want to do. I definitely know I want to be an Engineer now, and it makes it more clear that I should start my own business.
I encounter this problem in all of my Svelte projects- feels like I'm missing something. Fighting it with absolute positioning usually forces me to re-write a lot of CSS multiple times. Is there is a better way to solve this that I've overlooked?
Converting Angular components into Svelte is largely a mechanical process. For the most part, each Angular template feature has a direct corollary in Svelte. Some things are simpler and some are more complex but overall it's pretty easy to do.
We expect a certain pattern when validate devtool name, pay attention and dont mix up the sequence of devtool string. The pattern is: [inline-|hidden-|eval-][nosources-][cheap-[module-]]source-map.
I've only done components that need to/can be Svelte-ified. For some things, like RTL and layout grid, you can just use the MDC packages.
can you not also use a .babelrc?
This is very annoying and I think there must be a better solution.
Obviously we shouldn't rush into anything. But changes like these are best made earlier on in a project's lifecycle, so I'm eager to hear what people think so that we can start making some progress.
Some of the verbs implemented by systemctl are designed to provide a high-level overview in a human readable format. All that information is available over dbus, and/or journalctl, systemctl show. We could provide that information in json format, but there's a second problem. Information and format of information printed by e.g. systemctl status is not stable. Since the output is not suitable for programmatic consumption anyway, there's no need to provide it in a machine readable format.
In principle, this information is already available through other means, but it is actually a fair amount of work to gather it in this form, and I think it could be useful to open it up to programmatic consumption.
Although I agree that -o json should return proper JSON, believe the proper way for external tools like SaltStack etc. to talk to systemd is DBus. See also saltstack/salt#20392 - everything else is more or less just hack-ish and prone to break easily.
I'll want to generate, upload, and store a certificate for publishing NuGet packages.
If you have a better/simpler/"more official" solution, I'd still love to see it!
The "official" solution is to use submitErrors (see Erik's answer).
is this solution considered a hack or is something that we can use as an approved workaround in scenarios where we need to manually trigger validations?
The more official way to do this would be to run the check (you could even reuse this.validate) in onSubmit.
Focus on your application: forget about forms details like I'm dirty, field touched...
You may want to execute validations in a given specific order (this can be tricky especially when you have got asynchronous validations).
You can try to build a solution to tackle these issues on your own, but it will cost you time and money... why not use a battle-tested solution to handle all this complexity?
If you want to implement a form with a superb User Experience, you have to take care of many variables:
Form validation can get complex (synchronous validations, asynchronous validations, record validations, field validations, internationalization, schemas definitions...). To cope with these challenges we will leverage this into Fonk and Fonk Final Form adaptor for a React Final Form seamless integration.
Managing Form State (holding field information, check if a control has been touched, if the user has clicked the submit button, who owns the current focus...) can be tedious and prone to errors. We can get help from React Final Form to handle these challenges for us.
In the software industry we use "dependency" to refer to the relationship between two objects. We say "looking for dependents" for relationships to dependent things and "looking for dependencies" for relationships to prerequisite things, so it gets that connotation, but the literal meaning is the relationship itself, not the object. Finding a better word is exactly the point of the question
But it sounds like the library could use some way to setTouched()
I highly recommend setting a higher bound on the number of returned entities by each resolve function in your code.
Yeah I see what you're saying. In my case, I had a group of classes that relied on each other but they were all part of one conceptual "module" so I made a new file that imports and exposes all of them. In that new file I put the imports in the right order and made sure no code accesses the classes except through the new interface.
Doing so also means adding empty import statements to guarantee correct order of evaluation of modules (in ES modules, evaluation order is determined statically by the order of import declarations, whereas in CommonJS – and environments that simulate CommonJS by shipping a module loader, i.e. Browserify and Webpack – evaluation order is determined at runtime by the order in which require statements are encountered).
Here: dynamic loading (libraries/functions) meaning: at run time
Specifically, since Root, Rule and AtRule all extend Container, it's essential that Container is evaluated (and therefore, in the context of a Rollup bundle, included) first. In order to do this, input.js (which is the 'gateway' to all the PostCSS stuff) must import root.js, root.js must import rule.js before it imports container.js, and rule.js must import at-rule.js before it imports container.js. Having those imports ensures that container.js doesn't then try to place Root, Rule or AtRule ahead of itself in the bundle.
Replaced nested `require` statements with `import` declarations for the sake of a leaner bundle. This entails adding empty imports to three files to guarantee correct ordering – see https://github.com/styled-components/styled-components/pull/100
Modules from the following layer can require anything from all the previous layers, but not vice versa.
Any software that makes HTTP requests to other sites should make it straightforward to enable the use of a cache.
Note that the <WarningEngine/> component must be at the bottom of the form to guarantee that all the fields have registered.
Wondering how to get field state from multiple fields at once? People coming from Redux-Form might be wondering where the equivalent of Redux Form's Fields component is, as a way to get state from several fields at once. The answer is that it's not included in the library because it's so easy to write one recursively composing Field components together.
Use ponyfill.com for linking here.
formvalidation: path.resolve
Why use resolve.alias to point to 'vendors/formvalidation/dist/es6'? Why not just use an npm package and have package.json name module: 'vendors/formvalidation/dist/es6'
Then (I think) the examples below like
import luhn from 'formvalidation/algorithms/luhn';
would work the same but without that workaround.
Once again, this isn’t good or bad, it’s just the most efficient way to create something that is similar to something else
I'm okay with an overall design that allows people to plugin the parts they need in order to be able to generically support a compile-to-javascript language, but to bake in support for one singular solution because its popular is simply bad engineering.
Of all the compile-to-languages, the one that strikes me as having the least merit is JSX. It's basically a ton of added complexity for the sake of what boils down to syntax. There are no real gains in terms of language semantics in JSX.
Furthermore, JSX encourages bad non-dry code. Having seen a lot of JSX over the past few months, its encourages copypasta coding.
For event listeners we support the standard jsx naming convention onEventname (this is converted to on:eventname in svelte) as well.
An onevent event handler property serves as a placeholder of sorts, to which a single event handler can be assigned. In order to allow multiple handlers to be installed for the same event on a given object, you can call its addEventListener() method, which manages a list of handlers for the given event on the object.
However, in practice I do not think these tradeoffs are enough to justify logic-less templates.
Cons aren't covered by pros.
An alternative (maybe not good) would be to restrict {@const} to certain blocks like {#each} and {#if}. In both cases, it significantly reduces the "multiple ways to do the same thing" problem and avoids ergonomic and performance overhead of our current situation.
it also allows for more divergence in how people write there code and where they put their logic, making different svelte codebases potentially even more different due to fewer constraints. This last point is actually something I really value, I read a lot of Svelte code by a lot of different people and broadly speaking things look the same and are in the same places.
This is the Svelte version of this example: https://codesandbox.io/s/reactivity-react-responds-to-changing-props-forked-d2j44?file=/src/Label.js
Hannah Stepanek annotated the hell out of this reference. I would do well to read what she had to say.
They even named the main file react.js so when converting/migrating components from React you could (at least some of the time, perhaps) simply leave some of the imports as-is:
import {createHooks, useRef} from './react';
Svelte should make something like useEffect part of the framework so that this could work better and be less verbose.
I do like the direction Svelte is heading but I think this is one area that could be improved.
I'm suggesting there should be a way to write lifecycle related code that also responds to changing props, like how useEffect works. I think how React handles this could be a good source of inspiration.
I think it just needs a few changes, possibly non-breaking additions, to be as powerful as hooks, when it comes to abstracting lifecycle related logic, and making it easy to keep effects in sync with props.
I'm not sure I understand the problem, everything you are describing is already possible.
If Svelte came up with some kind of hooks like API maybe it could solve both these issues at once.
It provides several capabilities that are difficult to achieve with React alone, while being compatible with the newest features of React.
For reasons of compatibility and simplicity, it's best to use React's built-in state management capabilities rather than external global state.
I’d still be interested in Svelte making things easier so I’ve opened a feature request for Reactive statement cleanup functions.
Disclaimer: I’m new to Svelte so this isn’t so much a recommendation as it is a “I guess this is a way to do it 🤷♂️”
A “solution” to GR is more like a model in logic: it may satisfy a theory’s axioms but have other properties that are contingent (unless the theory is categorical, meaning that all of its models are isomorphic).
Solid supports templating in 3 forms JSX, Tagged Template Literals, and Solid's HyperScript variant.
Might have to cut my own version of the extension if its maintainers won't add support.
People constantly suggest that I should have just worked with a different library instead of writing another one.
It was clear no one was interested in what I was working towards.
Very few were interested in furthering the platform in the places they just took for granted.
but everything they were doing started to make sense
Do we need another JS UI Library?
React does not attempt to provide a complete "application library". It is designed specifically for building user interfaces[3] and therefore does not include many of the tools some developers might consider necessary to build an application.
The $: can also be used to trigger effects.
We can run effects when some data changes using watchEffect - it takes a function that runs whenever a reactive value used inside changes.
There's one downside to Reacts reactivity model - the hooks (useState and useEffect) have to always be called in the same order and you can't put them inside an if block.
createState and createSignal are improvements over React's useState as it doesn't depend on the order of calls.
MobX - for me personally MobX is a far better way to manage state than React Hooks. It doesn't care about the UI layer so it can be used outside the React ecosystem, and it's simple to mutate data.
Confidence to express ignorance is a super power. One good way I hone this skill is by saying “Nothing to add” when I have nothing to add, instead of repeating what other people said.
I don't even have it on my PC. That's why I didn't test the code myself. Don't have time for everything in this world
PR’s welcome. As I said I don’t have bandwidth to cross check all the bundlers & transpilers combo.
This library exports a single React Hook, useMethods, which has all the power of useReducer but none of the ceremony that comes with actions and dispatchers.
r self-r
This paragraph discuses the use of the word "bullshit" as it is used in every day life. Decide whether this is arguement, structure or both.
A Kind Word for Bullshit: The Problem of Academic Writin
Add MLA citation
I'm so tempted to toy around with this.
Since this issue seems to pop up periodically, it would be useful to turn this into a warning. It may not be elegant, but it prevents surprise blank screens due to a navigation error.
Not an actual fix.
do I really have to do something like that in order to have my local modules working? it's quite impracticable to explain it to a team! there's nothing a little bit more straightforward?
page components can have an optional preload function that will load some data that the page depends on. This is similar to getInitialProps in Next.js or asyncData in Nuxt.js.
It is showed as an error, but it is a warning as it doesn't break anything. I hate having warning/error in my console not coming from me. It is not justified as it's not bad practice imho
setContext / getContext can only be used once at component init, so how do you share your API result through context? Related: how would you share those API results if the call was made outside of a Svelte component, where setContext would be even more out of the question (and the API call would arguably be better located, for separation of concerns matters)? Well, put a store in your context.
let:hovering={active}
It seems like it should be the other way around:
let:active={hovering}
to make it look like a regular let assignment.
It's only when you consider what/how let:hovering on its own means/works that it makes a bit more sense that it is the way it is. When it's on its own, it's a little clearer that it's saying to "make use of" an available slot prop having the given name. (Very much like bind, where the LHS is also the name of the prop we're getting the data from.) Obviously we have to identify which prop we're wanting to use/pull data from, so that seems like the most essential/main/only thing the name could be referring to. (Of course, as a shortcut (in this shorthand version), and for consistency, it also names the local variable with the same name, but it wouldn't have to.)
Another even simpler way to remember / look at it:
export let inside that named component.Another example is bind: You're actually binding the RHS to the value of the exported prop named on the LHS, but when you read it (until you get used to it?) it can look like it's saying bind a variable named LHS to the prop on the RHS.