(hidden) 0hZvdpkVn | notes | kipras melnikovas

(hidden) 0hZvdpkVn

words:	0 + 1050 = 1050
last update:

(hidden) LC-vkVWoa

Linked Mentions (1 in 1 page)

December 10th, 2021 (1)

{{[[TODO]]}} prepare for [[(hidden) 0hZvdpkVn]]
- maybe "how codemods work - from first principles", or "how codemods & jscodeshift work - from the very basics"
- {{[[DONE]]}} maybe reach out to our production team / [[(hidden) _RMDwHiKR]] & ask for a good mic? not necessary, but would be good
  - {{[[DONE]]}} idk who's @ production team so just reach out to [[(hidden) _RMDwHiKR]]
  - {{[[DONE]]}} get response
  - {{[[TODO]]}} also borrow/buy an additional adapter for the macbook (tho i could use my linux setup just as well for this)
- {{[[TODO]]}} explain how a compiler (or interpreter) sees your program
  - high level summary of the below:
    - begin @ ast explorer
    - explain what we'll do today
      - we'll try to understand how codemods work
      - we'll write our own codemod
      - we'll learn how to use jscodeshift a bit
      - we'll see some real-world examples of codemods
      - we'll explore extra resources
        
        https://notes.kipras.org/codemods.html
        
        https://github.com/facebook/jscodeshift
        
        https://github.com/reactjs/react-codemod
        
        https://github.com/mui-org/material-ui/tree/master/packages/mui-codemod
        
        https://github.com/CodeshiftCommunity/CodeshiftCommunity
        
        https://www.codeshiftcommunity.com/
        
        https://github.com/dsherret/ts-morph
        
        .
    - a codemod is just code that modifies other code
    - "but what __is__ code?"
      - it's just text!
      - explore ast explorer
        
        select parser to flow
        
        write some code
      - why should i care? because we'll want to modify it!
    - doing it hardcore raw (eg regex), vs using existing libraries (eg jscodeshift from ex-fb guy)
    - ast explorer
      - come back to the same fn we wrote
      - modify the greeting
    - explain that this is what codemods are fundamentally about
    - ast explorer
      - another, similar fn
      - showcase filtering (basic)
      - showcase filtering (built-in)
      - showcase parent finding `.closest()`
      - showcase `.check()`ing
    - again, double down that this is how starting to add tiny bits of extra complexity might look like, but the fundamentals stay the same.
    - show external resources
    - explore some of our own codemods, show patterns
    - do overview that it's often not only code, but people, organizational problems as well
    - fin
  - show an example of writing some basic code in [[(hidden) eBB7dPivO]] and how the AST starts looking like
  - there are a few things at play - the parser, and then the "writer" which takes the parsed input, and produces the new output
  - ...now we want to somehow modify this code. so between the parsing and the writing (when we have the parsed code in the AST form, but we haven't written it to a file yet), we want to somehow modify the AST so that when we write in to the file, it will contain our modifications
  - so you need to modify the AST.
  - you __could__ write your own library to walk thru the AST, detect what kind of tokens (types of code) there are, but people have implemented this a long time ago - here comes jscodeshift.
  - it's a tool that allows you to easily find ~~tokens~~ nodes, to find nodes somehow related to them (searching in general), and then to check the node's properties, and then to modify either the node's properties, or the node itself (i.e. remove it, replace it w/ a different node, move it up or down or somewhere else around), and even create new nodes.
    - {{[[TODO]]}} do a better explanation of what a token is, both conceptually and w/ an example
    - {{[[TODO]]}} same w/ a node
  - show an example of the transformer (write something simple yourself first)
    - ```javascript export const parser = 'flow' export default function transformer(file, api) { const j = api.jscodeshift; // would it make sense to call `src` as `ast` instead? const src = j(file.source) return src.toSource(); } ```
    - be careful to __not__ over-simplify.
      
      maybe if we're fast, we can cover even the basics, but not be too boring for more experienced folks.
      
      also, gotta practice so that i don't ever get confused or dont know the solution immediately so that others dont have to waste time w/ me debugging
      
      {{[[TODO]]}} heh, maybe we can use actually component names? though meh, would involve more context, having simple js function w/o anything more to think about seems better
    - ```javascript export const parser = 'flow' export default function transformer(file, api) { const j = api.jscodeshift; const ast = j(file.source) ast .find(j.FunctionDeclaration, { id: { name: "greeting" } }) .forEach(path => { const { node } = path; console.log("node", node); node.id.name = "sayHi"; }) return ast.toSource(); } ```
    
    explain why we use .find instead of filtering in the forEach - because you can chain multiple .find's and it's just easier + more efficient + becomes clearer for what you're looking for from the very beginning
  - after that, explain that a "codemod" is just a collection of transforms that we combine and run one after another.
    - everything else is just more complexity, more advanced scenarios. but fundamentally, this is what a codemod is.
  - consider - should we write a jsx transformer as well?
    - probably yes, and just mention that one can skip to the next part of the video if they aren't interested
  - [[hindsight bias (in retrospect, it looks simpler than it actually was)]]
    - also mention that there are nuances, and to not expect everything to necessarily go smooth the first time - leave time for uncertainty:D
      - e.g. wrapping in JSXExpressionContainer
      - other challenges outside of the actual writing of the codemod - getting the "from/to" mappings if you're not familiar w/ the library, or e.g. if a designer decided them and has e.g. a spreadsheet that you'll need to parse, etc -- it's not all just writing of code, it involves other problems as well:D
      - then ofc the infra needed to run the codemods.
        
        could mention [[(hidden) C5ze2tqB8]] ofc, and that's where we started, but atm we've diverged so much from them, that we have somewhat different namings & structure & style as well
    - (hidden) WrCq5CZwG #[[(hidden) 7c2C8PgIV]]
      - (hidden) RjxKGQQrP
      - (hidden) sxwZl0gqY
  - also mention that a transform should do 1 thing and do it well, and for separate things you should have separate transforms, and combine them in the codemod.
    - but also mention that if the specific thing you're doing is the same, and the only thing that differs is the data (e.g. the component's name, or the attribute's name, or the attributes value / from-to mapping), then you can abstract it and just take in a "config" that has these - thus now you