I'm trying to use some of the hooks provided in behave API ( https://behave.readthedocs.io/en/stable/api.html?highlight=after_all#environment-file-functions ), but the function defined inside the environment.py file are never called. I've tried to move the file to several different folders ( features, steps ... ) but none of them seems to work.
Where is the project structure:
All look good, just change ctx to context in your hook.
It should look like in documentation: before_step(context, step). Keep the context.
Related
Say I have the following ReactJS component:
const MyComponent = () => {
const jsonData = require("./theJsonData.json");
return <ChildComponent jsonData={jsonData} />
}
Notice the require() call within the React component. Normally, I'd import the JSON using import, at the top of the file.
Will someone articulate to me WHY it is wrong to do this. I realize it's uncommon and I've never even seen this approach in the wild. But it does work. I'm looking for a well articulated explanation of WHY it's a bad approach.
Or, if you think it's a good approach, I'd love to learn that too.
UPDATE:
The question still stands, but I wanted to note a bit of research I just did. I just verified that all requires to this file, will reference the same object at run time. Each require() will be replaced by a call to __webpack_require__('the/path.json'). That call returns the same object, always. Even if you use it in different components.
So my initial concern of having 20 copies of the JSON data (20 objects for 20 components) is gone.
So now I really don't know what the issue is. Is there even an issue with this approach, or does it simply "look" wrong.
I think an important benefit that es6 imports provide over 'require' is the ability to reduce Javascript payloads.
Unlike with require statements, named imports allow you to only use dependencies you are actually using in your application, and webpack can shed the dependencies that weren't explicitly imported in your production build.
I'm trying to figure out what is the purpose of introducing something called custom hooks when its just a function. If I take the following example https://medium.com/from-the-scratch/react-custom-hooks-a-simple-intuition-if-you-still-cant-hit-it-off-8d27fa4ba10, if I don't use the use prefix for the hook, it all still works fine. With the introduction of this terminology called custom hooks I'm not sure whats the purpose of it, or should I just go on using standard functions.
What is the main advantage I get when using the use prefix for a custom hook or function apart from some simple linting features?
What is the main advantage I get when using the use prefix for a
custom hook or function apart from some simple linting features?
Reasons are stated in docs:
Do I have to name my custom Hooks starting with “use”? Please do. This
convention is very important. Without it, we wouldn’t be able to
automatically check for violations of rules of Hooks because we
couldn’t tell if a certain function contains calls to Hooks inside of
it.
In very basic words: You can reuse stateful logic between components, witch is not possible with regular functions. I would suggest that you read the documentation, because ReactJS has a pretty good one :)
Stay safe
Nothing. There is no difference between them. useFoo function is just a function. In source code, it was not dealt with specially. It is just little bit complicated, but no difference between regular functions.
use prefix is just a term, or just culture, whether you obey it is entrusted to you. Of course, obeying the culture bring us good result. But this and that have no connection. Custom hooks are just functions.
One pattern I've seen recommended is to use selectors to where possible to hide the shape of the store. That way if you need to update the shape of the store, you should be able to get away with only updating your selectors, and not other parts of the application.
However the same problem arises with the use of models within the state.
As one of many examples, let's assume I'm building a file system in Redux. I have a list of files which can either be a directory or a file.
My store might have a fileList property which contains an array of file ids as well as a files object which maps fileId to a file object.
Let's say I have a list of files and I want to, depending on whether it's a file or directory, have a different Item component (i.e. DirectoryItem and FileItem).
One way to achieve this is to do something like:
{
files.map(file => {
file.type = 'directory' ?
<DirectoryItem key={file.id} ...file /> :
<FileItem key={file.id} ...file />
)}
}
(or I could create a higher-order FileListItem component, for example, that does the check and renders either the DirectoryItem or FileItem)
However this might not be ideal because now my component needs to know the structure of the file object. I might want to add a different type of object (i.e. a shortcut file or shared file) and might decide that a type property isn't how I want to represent my data anymore. As such, I'd need to go and update all my components, etc.
If I were doing this in Backbone, for example, I would've probably chosen to define an isDirectory() function on my model, however that doesn't seem to be the Redux way of doing things.
One possible solution I can think of is creating a FileUtils helper class which exports an isDirectory method and takes a file object as a parameter.
Another option will be creating an isDirectory selector which takes a file id as a prop, doing something like:
(files, props) => state.files[props.fileId].type == 'directory'
If I were to create the selector, I suppose I would need to create a higher-order component to call the selector from.
Just wondering if either approach is recommended in Redux? Am I missing another approach that could help solve this issue?
The functional way of doing things simply prescribes tearing the method off of the object and calling it a function.
The recommended way to call it is to instead of having a this, simply pass a regular parameter. This is not a requirement. You can just use call or apply. That may seem real strange in js, but this may change soon with a new :: operator.
Now, you can give this function anything you like to help it get its data.
In your example
(files, props) => state.files[props.fileId].type == 'directory'
You pass it state (naming mistake there) and props and then use this info to come up with an answer. But you could instead choose to pass it a directory entry object. No need to go fetch it from state.
Note that this makes it very close to a method.
isDirectory = entry => entry.type === 'dir';
Now, because it's not getting state, it isn't selecting anything from state and is therefore not a selector.
However, it's plenty functional in nature. There really is no need or use to make life more complicated than that. Adding a higher order component or trying to shoehorn our problems into a more Redux-y way of doing things is needlessly complicating matters.
Selectors are recommended for selecting state so state usage is not tied to state shape. It's an abstraction layer, separating your mapStateToProps from your reducers.
Selectors are now considered part of the Redux Way, but that wasn't always true. And so, at your discretion, being informed of why something is done the way it is, you can then choose to not use it.
And, at your discretion, you can choose to substitute the current trend with your own version. It is highly recommended to do this, of course after consideration of alternatives.
Often the best solution is the one you come up with yourself. Being the most informed about your problem domain, you are uniquely qualified to formulate a matching solution.
Those who have developed great ideas that all of us feed off of and get inspiration from will probably move on from their viewpoint when something better comes along.
There isn't (and probably shouldn't be) a sacred paradigm. Everything is eligible for reconsideration. Occam's razor dictates that the simplest answer is most likely the right one.
And Redux is very much about simplicity. So to do things the Redux Way is mostly about doing things the straightforward way.
I'm interested in creating a mixin/decorator, but I don't want to declare it under every single component that uses it, but still have it available everywhere within the application.
Is that something that exists in react? Can I create tags that become automatically available within the context of the entire app?
How do analytics/i18n libraries work in react? Do you have to import them in every single file where you need translations or tracking?
Fresh beginner here.
One can use globals in React--just like with any other framework--but that's not really the 'React Way' of doing things. Relatedly, the equivalent of an 'app' in React would just be the top-level, root component.
Instead of relying on globals, one should instead either (1) import / require modules you need in one's component file; or, (2) pass needed functions and values from a parent to child component.
To implement the first method, one would need a bundler like Webpack or Browserify. So, for instance, if one wanted to use a i18n Gettext module like Jed, one would instantiate it and export it in one file and then import or require it in any component file that needs it.
As for the second method, one would pass down props from parent to child or use context. While props need to be manually passed down, context is always passed down to the entire subtree.
In the previous example, you could put Jed functions in a context, but the React team does warn: "If you have to use context, use it sparingly," and again, "Just as global variables are best avoided when writing clear code, you should avoid using context in most cases."
I have a project I'm developing which includes articles that can be commented on (comments stored in separate table of course). I want to perform pre logic on a field from each comment, wherever they are loaded through-out the app. The data logic I want to performed is from a custom written component.
The logical place to me that this could be achieved globally is from the comment model, but I could be wrong.
I'm not even 100% if I can use a component from a model, but I've been trying to do this logic using the afterFind() call-back function:
function afterFind($results) {
foreach ($results as $key => $val) {
if (isset($val['Comment']['created'])) {
$results[$key]['Comment']['created'] = $this->Dateconvert->howLongAgo($val['Comment']['created']);;
}
}
return $results;
}
I have tried echoing from inside this function and it doesn't actually seem to be getting called but searching hasn't revealed any functions that do, but I believe afterFind() is best to illustrate what I'm trying to achieve.
So I am looking for a solution where I can performed the post-load logic on articles comments, whether they are being loaded from other controllers with associations to comments or in the comments controller. Basically a global one hit solution :D
cakephp indicates that components are for controllers and behaviours for models and helpers for view...
knowing that first, you may also know that you can use any part of it wherever you want because cake still php, though is not recomended... if is a library of functions you may want to put it inside the libs folders and access it from there.
how, easy use App::import('component', 'nameComponent'); component can be lib, controller, etc..
Having said that, afterFind is a good place to do after load things, remember that this function is call ONLY when a find is used, if you use, any other like query or save or update it won't be called.
hope this helps you :)