---
# System prepended metadata

title: Untitled

---

:::danger
:fire: Please leave comments as feedback! 

I'm looking for improvements to the ideas covered as well as how I phrased them. 
But any frank feedback is welcome.  

I also want to find out:
* If I covered the idea I wanted to cover in the presentation proposal found at the bottom of this page.

Also note:
* These are just speaker notes, the slides will contain more pretty pictures and less text
:::


[TOC]


## The slides


* Obiectivul acum este:
    * sa avem un discurs coerent end to end, care are 
        * structura in ordine
        * toate cuvintele
    * ca sa putem incepe sa lucram la slideuri si separarea pe slideuri si ce contin ele
    * si apoi sa aducem imbunatatiri la ceva ce deja exista


### Intro
* Hi, I'm Mihai, I'm a FrontEnd Developer
* I work in the Application Development team in Romania. 
* We build applications for Ing employees.
* I will tell you about the app we are building, the troubles we had and how we overcame them.

### The project
   

#### Brief history of the three applications
* SPEECH
    * Let me tell you a short story of this project was born. In the beginning there were 3 happy independent applications. 
        * Record - front-office system, 
        * Fabo - back-office system and 
        * RITM - application used by the customer support team. 
                * Each of them was written in ASP.NET Web Forms and jQuery.
                * This is how they looked like. 
                * It looks like we're back to windows 98.
#### Their worthy successor
* SPEECH
    * Now as they were getting old, they went to a bar and talked a lot.
    * They realised it was time to retire. 
    * So one of them said, 
        * "Well guys we're getting old, we need a worthy successor"; 
        * "Yes but who?" 
        * So they looked around until they found someone to build them one.
        * It was going to be something fresh, modern and fast. 
        * It was going to be called NARC.
        * What is NARC ?
            * [insert gifu lu radu cu CRMs si apoi cu narc, apoi cu jocu de litere de la nacrm la narcm la narc]
#### The plan
* SPEECH
    * "But how do we pass our legacy?" Asked one of the old apps. 
    * "Well, it's not going to be in an instant I'll tell you that", said the builders. 
    * "We're going to do it in stages. 
        * We will do it app by app, and screen by screen, using iframes for the old modules. 
        * We'll decommision the old ones as the new modules are ready. And we are going to start with Record.
            * Great, so we have a plan.
#### The ideal scenario
* SPEECH
    * Now, you know how we have theory on one side and reality on the other. 
        * In theory there is no difference between theory and practice, while in practice there is.
    * We have this wonderful place where everything works just as it should.
    *  The pieces work out of the box, and fit together like legos
        *  [screen cu tpa, ing-web, orange juice] 
             * We've got guiding principles and some helper libraries in TPA ; ready-made web-components in ing-web; and a defined styleguide for the components in the Orange Juice. `canExtend`
#### What really happened - Real Life
* SPEECH
    * Here comes Real Life.
    * It's more unexpected, complex and sometimes just random.
    * Ups and downs.
    * So Let me tell you how we learned to navigate through this and what we learned along the way

### The start

* We knew a few things at the start.
* We knew we had to build a rocket, from a few parts.
* We didn't know how they fit together
* There wasn't any blueprint.
* We knew The road to production  is long and filled with surprises.
* And we knew we had to carry a big shipwreck along with us
* So these were the three parts
    * the rocket
    * The road to production
    * the the shipwreck
* Three parts? Three places where things can go wrong.
* Right?
* Well, not really.
* Because those parts interact and this creates friction between them.
   
### The milestones and turning points
#### First contact
* SPEECH
    * But let's start with the start. 
    * Our big bang. 
    * On the 18th of January Radu, my colleague, sent me a presentation - "The evolution of the guide for the web".
    * It gave us guiding principles for our own application
        * use the platform
        * consistent experience
        * assemble your apps
    * Then it promised the tools to enable those principles
        * ing-web - a component package built on open source libraries, using the platform via web-components
        * tpa-web - guidelines to structure your app and helper libraries
        * orange juice - a design system, so everyone knows they are using an ing app

#### Uncertainty and excitement
* Separating the mockups into component types set out by TPA
* SPEECH
    * So we were getting excited, but we still didn't know how to apply what we found.
    * So We went through some links in the presentation.
    * A We found a real world implementation for structuring the app.
    * Then, more questions. 
    * How do we apply this for our app ?
    * {SHOW MOCKUPS THAT ARE SPLIT INTO COMPONENTS AND LABELS}
    * So we split our app into different components, according to tpa guidelines.
    * This was before building anything, 
    * so we knew this was going to change
    * But it's still a great exercise.
    * {MAYBE INSERT MOCKUPS THEN, SCREENSHOT NOW WITH HOW THE APP IS SPLIT}
        * This is how we started, 
        * this is how it is right now in our app
    * That's all we had back then
    * Some idea of the tools we'll use, mockups and a lot of questions.

#### The first visit
* Uncharted teritorry, validated a few of our attempts of making sense of the guidelines
* ensured a second visit
* SPEECH
    * Some big news soon came.
    * We will have a visit from the TPA and ING-WEB teams.
    * We wanted to have lots of questions answered
    * So we prepared
    * We wanted to validate our component separation
        * {INSERT IMAGE WITH COMPONENT SEPARATION}
    * And we wanted to understand layering
        *  {INSERT SCREEN WITH TPA LAYERING}
    * So We made a poc to make sure we understood the tpa layering
        * {LINK CU CUM ARATA REPO-ul de POC}
        * This is how it looked like
    * At the end of the meeting, we had lots of answers.
    * The bad part is this created more questions
    * So we arranged another visit.
    * And on this next visit the plan was to work side by side on building this rocket.
    * We were excited!
    * This was our confidence in the tools before and after we set up the visit
        * {INSERT GRAPH WITH LOW AND HIGH CONFIDENCE BEFORE AND AFTER}
    * Quite the dramatic change.

#### Baby steps and still a lot of uncertainty
* SPEECH
    * Now, let's start building.
    * Should we start from scratch?
    * No. Remember the principle: Assemble your apps, don't start from scratch
    * We looked for a starter project in our internal repositories
    * We didn't find anything.
    * Then, we looked in open source projects and found something.
    * Create-lit-app.
    * It had everything we needed
        * {Show Code}
        * It had web components, based on lit-element and lit-html
        * A build tool
        * A test setup
        * Support for IE11
    * It would be crazy NOT to use it
    * So we did.
    * Now we at least had something on the screen.
    * And still a lot of questions?
        * How do we manage state ?
        * How do components communicate ?
    * Redux was TPA's recommendation, but in an async application redux is not enough.
        * {SHOW EXAMPLE OF MESSY REDUX WHEN ASYNC IS INVOLVED}
    * We had guidance for other parts of the app...
    * so why not for this?
        * That's what we thought back then
    * So we just put it in our list of unanswered questions

#### First phantom bug

* The more we experimented, the more our confidence grew.
* Until one day, when our screen went blank
* The app was still loading
* We checked the console, no errors.
* Hmm, What could be wrong?
* After a few tries, we noticed the render function didn't work.
    * {Show picture of html fn import from ing-web and from lit-html}
    * It didn't work when imported straight from ing-web
    * It did work when imported from lit-html
* that's strange
* I guess I'll talk to someone from ing-web
* I prepared a sample repo
    * {Show how the example looked like}
* Sent it
* And didn't expect to hear back anytime soon
* He got back to me the next day. YAY
    * {INSERT YAY SOUND}
* It worked on his machine. Nooh
    * {INSERT NO SOUND}
* No solution, but... the response was quick.
* To be fair, they did say there will be a great and quick support system around these tools.
* But I thought: 'Pffft... Yeah. Sure. Big Company, Big Words.'
* But boy was I wrong
* If you don't believe me, Try to ask something on the mattermost channel.
    * {insert link}
* If you are struggling with a bug, or a specific problem, give the ing-web community a chance.
* In the end, we updated our app and the bug vanished.
* Like a ghost, never to be seen again.

#### Prepare for lift off

* ce vreau sa ilustrez aici
    * ce aveam gata pana aici
    * cum a functionat intalnirea
        * am facut storyuri multe, le-am prioritizat si tot nu am putut sa le ducem la capat pe toate

* SPEECH
* We had a starter project and some conventions
* {Show screen}
* We also had big plans.
* We wanted to work on our most important components
* One of them is the grid
* The grid is an interesting story.
* There wasn't any internally we could use.
* The think ingat the time was to build our own, and contribute it back to ing-web.
* We first thought, maybe they want us to build it from scratch
* As an engineer, you might think "Yes, let's build it. It's a great challenge".
* But, we had a few issues
* A lot of requirements
* web components were new to us, 
* and a planned June release.
* Then we looked at what's available
    * There were only two options.
    * Two big open source projects that are already proven
        * They are used by other companies in production.
        * They both had an enterprise version.
* So we built a simple wrapper component for the vaadin-grid.
    * {SHOW CODE HERE}
* We still didn't know two things
* One. Can we contribute it like this?
    * not from scratch etc.
* And two. If yes, then how do we do it?


#### The second visit and a new hope


### Priorities - sources of friction
* So when they visited, we tried to work this out as well.
* We discovered they were great guys
* Reasonable and helpful.
* And that there is a process for something to get into ing-web
* You first create some specs
    * {image}
* Then these get discussed and finalised
* Only then, a team gets assigned to build that component.
* But for the grid, the choice was to build their own.
* They had additional requirements, a11y wise as well as security wise.
    * {ILLUSTRATE CSP}
* It also had a much lower priority for them than for us.
* So we went our own way.

### The good
* Despite this, their visit gave us a few BIG Wins.
* One. A better structure to our project, that encourages separation
    * {SHOW IMAGE WITH BEFORE AND AFTER}
* Two. Useful file naming conventions, encouraged by TPA
    * {SHOW IMAGE WITH FILE CONVENTIONS}
* Three. Coding Standards. 
* They are enforced through Pre-commit hooks.
* We now have these for linting, formatting and consistent commits.
    * {SHOW IMAGE WITH THE SCRIPTS}
* This just makes it easy to do something the right way and just makes some mistakes harder.
* No project should start without these.
* It prevents a lot of discussions, around code style, spacing.
* This is something that should be enforced.
* They should be taken as a given from the start.
* Otherwise, we as developers might start a war over this.
* It's for our own sanity


#### Confidence boost & Other important decisions
* ce vreau sa zic aici:
    * ca vizita ne-a ajutat sa ne dam seama ca altii au alte prioritati
    * ca noi le avem pe ale noastre
    * ca nu exista recomandari pentru toate librariile si ca putem sa punem ce avem nevoie si sa luam decizia asta pentru noi.

* The visit itself was very productive
* We made great improvements to our rocket.
* We also understood a few things.
* First. There are people behind these entities and they are willing to help.
* Second. Not everything is set in stone. 
* Using web components is, ing-web is, tpa structure is. But for other needs you can make decisions on your own.
* This is what we did when we introduced redux-saga.
* We wanted a way to handle async data flows, isolate business logic from the view 
    * {SAMPLE REDUX SAGA CODE from our app}
* and make flows easier to test in isolation.
    * {REDUX SAGA TEST PLAN}
* Third. Turns out Explicit and direct communication really helps.
* Hm. Strange.

* So now the rocket was on its way.
* We solved a few communication issues, that could have derailed us but didn't.
* What can go wrong now.
* Ah yes, the shipwreck we had to carry.

#### IE11 is HELL

* IE11 is HELL
* No really, just look.
* This is not a coincidence.
* It's a black hole. It sucks everything in.
* Your time, your effort. It gives nothing back.
* It's like a ship on the sea with small holes in it.
* You need to patch the holes.
    * {EXAMPLE with the $id and $name selectors}
* Did you know about this? 
* This is not something a polyfill can patch.
* You can almost hear the water coming into your boat
    * {WATER SOUNDS}
* We stopped this leak
* We replaced the selectors
* Easy, right?
* But where there's a crack, there are always more.
* And They kept getting bigger.
* Like this bug, that appeared in lion
    * https://github.com/ing-bank/lion/blob/28590dbf523bf72ed7930eba92e6ab59e70ffdac/packages/field/src/FormControlMixin.js#L150
* This is simply a polyfill that doesn't behave like its native implementation.
* Soon enough your time is spent more on fixing these holes than building the rocket.
* This is time, forever wasted.
* Our team alone reported 4 bugs to lion.
    * {Screen with bugs reported}
* But we realised early that putting out fires like this is not smart.
* So we became proactive.
* We added a checkmark to our pull-request template
* Works on IE11.
* So no branch will be merged without first making sure it works on IE11.
* It's a small change, but great for peace of mind.


#### Growing pains.

* Now the rocket was up and running.
* Our team came together and built this.
* We had a lot of outside help at the start.
* We dealt with a few issues early on.
* Some technical, some organisational.
* We patched a few big holes on the shipwreck.
* But also managed to keep our focus on navigating the rocket to production.


#### The first release
* SPEECH
    * This is how the project looked like at release
        * {SHOW IMAGE OF PROJECT AT RELEASE}
    * Looks good, but a work in progress
    * What do you think happened at release ?
    * Nothing
    * I just wanted to say that. 
    * We were ready.

#### Paying it forward
*  Helping others with their own rockets
*  SPEECH
    *  Building this, teaches you a few things about the tools you use and what you can do with them.
    *  We had people help us at the start.
    *  It was invaluable.
    *  Now it was our turn.

    *  Team X was was planning a rewrite of their own.
    *  Using ing-web.
    *  So we held 1 day workshop for them, to help them familiarise with ing-web.
    *  We tackled most of their questions.
    *  They were quite similar to the ones we had when we first started.
        *  * Having a page with a grid
                        * Setting up a skeleton project
                        * Routing
                        * State management
                        * Component communication
    *  Sometimes this is all you need to kickstart your project.

#### Competing concerns hell
*  stuck between a rock and a hard place
*  SPEECH
    *  But back to our project.
    *  Our most recent problem is even juicier.
    *  It's both technical and organisational.
    *  They feed into one another.
        *  {Ilustreaza cele doua prin cercuri}
    *  You have the old app and the new app on one side
    *  Business constraints and UX styling constraints on the other
        *  {ilustram ce scriu in astea doua paragrage}
    *  And now let me illustrate the problem
    *  Our users use the app at 150% zoom
    *  They do this because the font in the old app is small
    *  The font in the new one is normal
    *  But the old and the new run at the same time.
        *  {imagine cu grid vechi si bara de sus noua}
    *  The business constraints
        *  everything on one page, no additional scrolling
        *  So using css scale to increase the size of the old app is out of the question
    *  UX constraints
        *  Ing-web components are customizable
        *  Up to a point.
        *  This is to maintain visual identity.
        *  I get it
        *  But this also means we can't change the css without extending the components.
    *  So we did
    *  It's a compromise, It's not supported. But it's something we had to do
    *  At least for the moment
        *  {show image of extension of components}
    *  Let me tell you how I see the solution for this.
    *  You bring the decision makers to a table
    *  You let them come to an agreement.
    *  I as a developer don't have that decision making power.
    *  But I am impacted If the two don't talk.
    *  I have to make compromises.
    *  These can lead to technical debt.
    *  And as you know, all debt must be paid. Eventually.

 ### present and future
 
 #### major questions but still ready
* lazy loading
* ready for independent publishing 
* exploring micro-frontends
* SPEECH 
    * This hasn't stopped us however.
    * This is how the project looks like now
        * {show project structure}
    * Thanks to the tpa provided router, we lazy load our page components
        * {show them page component}
    * We also load their related sagas and redux reducers lazily as well
        * {show example of this}
    * You can't see the difference between lazy and eager loading in Chrome
    * But in IE11...
    * Well, just look
        * {show video of difference}
    * Right now, our next step is exploring micro-frontends.
        * {SHOW EMPTY PAGE}
    * This is how far we are in our exploration.
    * `canExtend` with performance improvement in IE11
        * {SHOW VAADIN SEARCH}


### Some lessons
#### Tackle One Thing at a Time
* SPEECH
    * First understand your tools, then improve and contribute. In this order.
    * Remember every team has their own objectives and timelines and their own project. 
    * Make sure your house is in order before focusing on other objectives.
    * Ours was to learn the tools we were given
    * To get the rocket to production
    * In one piece.

#### Experiment a lot at the start. Ask questions
* SPEECH
    * Building POC's early helped us a lot
    * You don't know what you don't know until you start building.
    * Building early means, making mistakes early.
    * Making mistakes early, means learning early.
    * Learning early means improving while the stakes are low

#### Find mentors
* others who used the same tools
* SPEECH
    * People who already use the tools you are planning to use, know more.
    * Plain and simple.
    * We were lucky to get this for FREE.
    * But if you are in a similar situation
    * Reach out to someone who already did something similar.

#### Help yourself, then help others.
* given the same amount of time what would you focus on, what is more important
* SPEECH
    * This might be controversial.
    * We wanted to contribute to ing-web.
    * In the end we didn't.
    * We will in the future.
    * But at the start we were barely familiar with the tools and the process.
    * Our focus was to build a solid foundation for our app.
    * And you know. Projects are messy at the start.
    * But as they mature and stabilize, you can focus on other things.
    * It's the same principle in a plane when the oxygen masks come down. 
    * You first help yourself so you can then help others.
#### Speak up on what doesn't seem right, early and often, don't let issues pile up.
* SPEECH
    * I think we can only grow if we let our truth out.
    * My experience is subjective.
    * I could have easily just shut up.
    * Take up this technical debt, and not speak about something like conflicting requirements
    * Like those between UX and the Business.
    * It can be interpreted in a number of ways.
    * But I think it just shows, we care.
    * We care about what we build
    * We care about our users.


* Thank you for listening and thank you for everyone involved in this project.


### A few thank yous
* Team
* Pascal and indirectly everyone who helped him
* ing-web
* TPA


## What was written in the presentation proposal
### The Synopsis

Learning to steer a rocket with no driving licence while towing a shipwreck

Supercharged development with web components, ing-web and tpa architecture....with IE11. A 6 month journey navigating with one leg into the future of the web and another into the depths of IE11 hell.        

Gradually migrating a legacy CRM  to web-components, ing-web and tpa-architecture. 
How we started, how the project evolved, where we are now and next steps. 
All explained with a focus on highlighting the interactions and sometimes conflicting objectives between the project team and the library teams (ing-web, tpa), and how we solved them.
 
The objective here is to provide teams starting new projects with insight into the benefits and also the problems of working with ing-web and tpa, the people and the libraries and how to get over those bumps and deliver your project


### FOCUS

- Conflicting objectives between the project team and library teams and how we solved them.

### OBJECTIVE

- ing-web and TPA benefits, problems and solutions or workarounds to problems


## Tags
`toBeDeleted` ; `detaliu`; `necesitaImagine`


### What’s with the title?

#### Learning to steer
* Find our way successfully to production
#### rocket
* Speed
* state of the art technology - web components
* Many parts little margin for error
#### no licence
* no previous experience with the enforced technologies - web components, ing-web, tpa structure
#### towing a shipwreck
* Bringing our own baggage to this.
* Why we use IE. No! Why we HAVE to use IE.





## Feedback 29.10.19

* the rocket was up and running twice said
* prepare questions
    * Why are you stuck with IE11
* sync slides with speak
    * slides 22; 48; am sarit aici
    * 62 
    * team X - Wholesale Banking et 9
* slide 54 - POC - project structure.
* slide 39 - dupa ce vorbesc de shipwreck. zic pe scurt de ce suntem legati la gat de IE11
* sa ilustrez ca ne-am consultat pentru sagas. chiar daca decizia am luat-o singuri.
* business requirements explained. --> fiecare click conteaza.


* feedback Dan 29.10.19
* O sa facem screen by screen sa nu includem iframes
    * sa se inteleaga ca nu asta e directia pe care o luam
    * iframes reprezinta trecutul nu viitorul
* why we're stuck 
    * activeX to communicate with peripheric device. there is a plan to decommission this, and make it available in edge si chrome.
* grid
    * don't mention accessibility the CSP.
* coding standards
    * tool, help 
    * at the start e mai periculos. e bine sa fie la inceput.
* redux-saga
    * ceri feedback, pornesti discutia
    * dar tu stii cel mai bine ce e acolo si tu ramai cu decizia la final
* la release
    * a trecut releasul
    * am asteptat, am asteptat si n-am primit nimic si ne-am intrebat daca s-a promovat sau nu - chiar a ajuns in productie ?
* paying it forward
    * coding standards pt ceilalti
* lazy vs eagers
    * 2 chrome, 2 ie
* future
    * efort la ie11
    * agream cu business owners ca trebuie gasita o solutie pt ie11
    * exploring solution to give up ie11
* change from might to will in the future
* help yourself -
    * make explicit that we used ce era in ing-web
    * doar ca nu am contribuit nimic
* pun slide cu ce am folosit
* Sectiune pe ing-web contribution. we now feel ready for our own contribution
    * bug reports
    * am incercat si cu o componenta
    * acum ne simtim destul de maturi sa contribuim
* ce am folosit din ing-web

### feedback 5.11.2019
* care e treaba cu tpa, ilustrat vizual si cu celelalte
* vizual
    * Recor...d
    * 

